对 SQL 数据使用 IEnumerable 返回类型是否有任何陷阱？

我的问题是关于SQL连接状态、负载等，基于以下代码：

public IEnumberable<MyType> GetMyTypeObjects()
{
  string cmdTxt = "select * from MyObjectTable";

  using(SqlConnection conn = new SqlConnection(connString))
  {
    using(SqlCommand cmd = new SqlCommand(cmdTxt, conn))
    {
      conn.Open();
      using(SqlDataReader reader = cmd.ExecuteReader())
      {
         while(reader.Read())
         {
            yield return Mapper.MapTo<MyType>(reader);
         }
       }
    }
  }
  yield break;
}

我可以看到，如果有许多进程运行类似的代码，并且 IEnumerable 对象的迭代之间的执行时间很长，那么这可能是一个问题，因为连接打开的时间会更长，等等。但是，这似乎也有可能减少 CPU 使用率在 SQL Server 上，因为它仅在使用 IEnumerable 对象时返回数据。它还降低了客户端的内存使用量，因为客户端在工作时只需加载一个 MyType 实例，而不是加载所有出现的 MyType（通过迭代整个 DataReader 并返回一个列表或其他内容）。

• 您是否可以想到您不想以这种方式使用 IEnumerable 的任何情况，或者您认为它非常适合的任何情况？

• 这会给 SQL Server 带来什么样的负载？

• 这是您会在自己的代码中使用的东西吗（除非提及 NHibernate、Subsonic 等）？

-

这不是我会遵循的模式。我不会像担心锁那样担心服务器上的负载。遵循这种模式将数据检索过程集成到您的业务逻辑流中，这似乎是一个万能的麻烦秘诀；你不知道迭代方面会发生什么，并且你正在将自己插入其中。一次性检索您的数据，然后在您关闭读取器后允许客户端代码对其进行枚举。