C# IEnumerator/yield 结构可能不好？

Question

背景：我从数据库中获取了一堆字符串，我想返回它们。 传统上，它会是这样的：

public List<string> GetStuff(string connectionString)
{
    List<string> categoryList = new List<string>();
    using (SqlConnection sqlConnection = new SqlConnection(connectionString))
    {
        string commandText = "GetStuff";
        using (SqlCommand sqlCommand = new SqlCommand(commandText, sqlConnection))
        {
            sqlCommand.CommandType = CommandType.StoredProcedure;

            sqlConnection.Open();
            SqlDataReader sqlDataReader = sqlCommand.ExecuteReader();
            while (sqlDataReader.Read())
            {
                categoryList.Add(sqlDataReader["myImportantColumn"].ToString());
            }
        }
    }
    return categoryList;
}

但是我认为消费者会想要迭代这些项目并且不关心其他太多，而且我不想将自己限制在列表中，所以如果我返回 IEnumerable 一切都很好/灵活。 所以我想我可以使用“yield return”类型设计来处理这个...类似这样的事情：

public IEnumerable<string> GetStuff(string connectionString)
{
    using (SqlConnection sqlConnection = new SqlConnection(connectionString))
    {
        string commandText = "GetStuff";
        using (SqlCommand sqlCommand = new SqlCommand(commandText, sqlConnection))
        {
            sqlCommand.CommandType = CommandType.StoredProcedure;

            sqlConnection.Open();
            SqlDataReader sqlDataReader = sqlCommand.ExecuteReader();
            while (sqlDataReader.Read())
            {
                yield return sqlDataReader["myImportantColumn"].ToString();
            }
        }
    }
}

但是现在我正在阅读更多关于yield的内容（在这样的网站上...msdn似乎没有提到这一点），它显然是一个惰性评估器，它保持填充器的状态，以预期有人询问下一个值，然后只运行它直到它返回下一个值。

在大多数情况下这似乎很好，但是对于数据库调用，这听起来有点冒险。 作为一个有点人为的例子，如果有人要求一个 IEnumerable ，我从数据库调用中填充，完成一半，然后陷入循环......据我所知，我的数据库连接正在进行永远保持开放。

在某些情况下，如果迭代器没有完成，听起来像是自找麻烦……我错过了什么吗？

Answer 1

这是一种平衡行为：您是否希望立即将所有数据强制写入内存以便释放连接，或者您希望从流式传输数据中受益，但代价是一直占用连接？

在我看来，这个决定可能应该由呼叫者决定，他们更了解自己想做什么。 如果您使用迭代器块编写代码，则调用者可以非常轻松地将流形式转换为完全缓冲形式：

List<string> stuff = new List<string>(GetStuff(connectionString));

另一方面，如果您自己进行缓冲，则无法调用者可以返回到流模型。

因此，我可能会使用流模型，并在文档中明确说明它的作用，并建议调用者做出适当的决定。 您甚至可能想提供一个辅助方法来基本上调用流版本并将其转换为列表。

当然，如果您不相信调用者会做出适当的决定，并且您有充分的理由相信他们永远不会真正想要流式传输数据（例如，无论如何它都不会返回太多），那么请选择列表方法。 无论哪种方式，记录它 - 它很可能会影响返回值的使用方式。

当然，处理大量数据的另一种选择是使用批处理 - 这在某种程度上偏离了最初的问题，但在流式传输通常很有吸引力的情况下，这是一种不同的考虑方法。

Answer 2

使用 IEnumerable 并不总是不安全。 如果您离开框架调用GetEnumerator（这是大多数人都会做的），那么您就安全了。 基本上，您与使用您的方法的代码的仔细程度一样安全：

class Program
{
    static void Main(string[] args)
    {
        // safe
        var firstOnly = GetList().First();

        // safe
        foreach (var item in GetList())
        {
            if(item == "2")
                break;
        }

        // safe
        using (var enumerator = GetList().GetEnumerator())
        {
            for (int i = 0; i < 2; i++)
            {
                enumerator.MoveNext();
            }
        }

        // unsafe
        var enumerator2 = GetList().GetEnumerator();

        for (int i = 0; i < 2; i++)
        {
            enumerator2.MoveNext();
        }
    }

    static IEnumerable<string> GetList()
    {
        using (new Test())
        {
            yield return "1";
            yield return "2";
            yield return "3";
        }
    }

}

class Test : IDisposable
{
    public void Dispose()
    {
        Console.WriteLine("dispose called");
    }
}

您是否可以努力使数据库连接保持打开状态也取决于您的体系结构。 如果调用者参与事务（并且您的连接是自动登记的），那么框架无论如何都会保持连接打开。

yield 的另一个优点是（当使用服务器端游标时），如果您的消费者想要退出，您的代码不必从数据库中读取所有数据（例如：1,000 个项目）较早的循环（例如：第 10 项之后）。 这样可以加快查询数据的速度。 特别是在 Oracle 环境中，服务器端游标是检索数据的常用方法。

Answer 3

你没有错过任何东西。 您的示例展示了如何不使用收益回报。 将项目添加到列表中，关闭连接，然后返回列表。 您的方法签名仍然可以返回 IEnumerable。

编辑：也就是说，乔恩有一个观点（太惊讶了！）：在极少数情况下，从性能角度来看，流式传输实际上是最好的选择。 毕竟，如果我们在这里讨论的是 100,000（1,000,000？10,000,000？）行，您不希望首先将其全部加载到内存中。

Answer 4

顺便说一句 - 请注意，IEnumerable方法本质上是 LINQ 提供程序（LINQ-to-SQL、LINQ-to-Entities）的谋生手段。 正如乔恩所说，这种方法有其优点。 然而，也存在一些明确的问题——特别是（对我来说）在分离（组合）方面| 抽象。

我在这里的意思是：

• 在 MVC 场景中（例如），您希望“获取数据”步骤实际获取数据，以便您可以测试它在控制器上的工作情况 em>，而不是视图（无需记住调用.ToList()等），
• 您无法保证另一个 DAL 实现能够 流式传输数据（例如，POX/WSE/SOAP 调用通常不能流式传输记录）； 并且您不一定想让行为产生令人困惑的不同（即在一个实现的迭代过程中连接仍然打开，而另一个实现则关闭）

这与我的想法有些联系：实用 LINQ。

但我应该强调 - 有时流媒体确实是非常理想的。 这不是一个简单的“总是与从不”的事情......

Answer 5

强制评估迭代器的稍微简洁的方法：

using System.Linq;

//...

var stuff = GetStuff(connectionString).ToList();

Answer 6

不，您走在正确的道路上...收益将锁定读者...您可以在调用 IEnumerable 时进行另一个数据库调用来测试它

Answer 7

唯一会导致问题的情况是调用者滥用 IEnumerable 协议。 正确的使用方法是当不再需要它时调用Dispose。

由 yield return 生成的实现将 Dispose 调用作为执行任何打开的 finally 块的信号，在您的示例中它将调用 对您在 using 语句中创建的对象进行 Dispose。

有许多语言功能（特别是 foreach）使得正确使用 IEnumerable 变得非常容易。

Answer 8

您始终可以使用单独的线程来缓冲数据（可能缓冲到队列），同时也执行 yield 来返回数据。 当用户请求数据（通过 yield 返回）时，将从队列中删除一个项目。 数据也通过单独的线程不断添加到队列中。 这样，如果用户请求数据的速度足够快，队列就永远不会很满，您不必担心内存问题。 如果他们不这样做，那么队列就会填满，这可能还不错。 如果您想对内存施加某种限制，则可以强制执行最大队列大小（此时另一个线程将等待项目被删除，然后再向队列添加更多项目）。 当然，您需要确保在两个线程之间正确处理资源（即队列）。

作为替代方案，您可以强制用户传入一个布尔值来指示是否应缓冲数据。 如果为 true，则数据将被缓冲并尽快关闭连接。 如果为 false，则不会缓冲数据，并且只要用户需要，数据库连接就会保持打开状态。 使用布尔参数会迫使用户做出选择，从而确保他们了解问题。

Answer 9

我已经撞到这堵墙好几次了。 SQL 数据库查询不像文件那样易于流式传输。 相反，仅查询您认为需要的数量，并将其作为您想要的任何容器（IList<>、DataTable 等）返回。 IEnumerable 在这里不会为您提供帮助。

Answer 10

您可以做的是使用 SqlDataAdapter 并填充 DataTable。 像这样的事情：

public IEnumerable<string> GetStuff(string connectionString)
{
    DataTable table = new DataTable();
    using (SqlConnection sqlConnection = new SqlConnection(connectionString))
    {
        string commandText = "GetStuff";
        using (SqlCommand sqlCommand = new SqlCommand(commandText, sqlConnection))
        {
            sqlCommand.CommandType = CommandType.StoredProcedure;
            SqlDataAdapter dataAdapter = new SqlDataAdapter(sqlCommand);
            dataAdapter.Fill(table);
        }

    }
    foreach(DataRow row in table.Rows)
    {
        yield return row["myImportantColumn"].ToString();
    }
}

这样，您一次性查询所有内容，并立即关闭连接，但您仍然懒惰地迭代结果。 此外，此方法的调用者无法将结果转换为 List 并执行不应该执行的操作。

Answer 11

不要在这里使用产量。 你的样品很好。