使用为 SqlDataReader 中的每一行调用委托的方法有哪些缺点？

Question

当我发现一个新想法时，我总是坚持下去，看不到它的任何弱点。当我开始在一个大型项目中使用这个新想法时，糟糕的事情就会发生，并且在几个月后发现这个想法非常糟糕，我不应该在任何项目中使用它。

这就是为什么，有了一个新想法并准备在一个新的大型项目中使用它，我需要您对此的意见，尤其是负面的意见。

---

很长一段时间，我厌倦了在必须直接访问数据库的项目中一次又一次地输入或复制粘贴以下块：

string connectionString = Settings.RetrieveConnectionString(Database.MainSqlDatabase);
using (SqlConnection sqlConnection = new SqlConnection(connectionString))
{
    sqlConnection.Open();

    using (SqlCommand getProductQuantities = new SqlCommand("select ProductId, AvailableQuantity from Shop.Product where ShopId = @shopId", sqlConnection))
    {
        getProductQuantities.Parameters.AddWithValue("@shopId", this.Shop.Id);
        using (SqlDataReader dataReader = getProductQuantities.ExecuteReader())
        {
            while (dataReader.Read())
            {
                yield return new Tuple<int, int>((int)dataReader["ProductId"], Convert.ToInt32(dataReader["AvailableQuantity"]));
            }
        }
    }
}

所以我做了一个小类，它允许编写类似的东西来做同样的事情上面：

IEnumerable<Tuple<int, int>> quantities = DataAccess<Tuple<int, int>>.ReadManyRows(
    "select ProductId, AvailableQuantity from Shop.Product where ShopId = @shopId",
    new Dictionary<string, object> { { "@shopId", this.Shop.Id } },
    new DataAccess<string>.Yield(
        dataReader =>
        {
            return new Tuple<int, int>(
                (int)dataReader["ProductId"],
                Convert.ToInt32(dataReader["AvailableQuantity"]);
        }));

第二种方法是：

• 写得更短，

• 更容易阅读（至少对我来说；有些人可能会说，实际上，它的可读性要差得多），

• 更难犯错误（例如在第一种情况下，我经常忘记在使用它之前打开连接，或者我忘记 while 块等），

• 在 Intellisense 的帮助下更快，

• 更加简洁，特别是对于简单的请求。

示例：

IEnumerable<string> productNames = DataAccess<string>.ReadManyRows(
    "select distinct ProductName from Shop.Product",
    new DataAccess<string>.Yield(dataReader => { return (string)dataReader["ProductName"]; }));

使用简单的 ExecuteNonQuery、ExecuteScalar 和 ReadManyRows 以及通用的 DataAccess.ReadManyRows 实现此类操作后在一个小项目中，我很高兴看到代码更短并且更易于维护。

我只发现两个缺点：

• 需求中的一些修改将需要大量的代码更改。例如，如果需要添加事务，使用普通的SqlCommand方法就很容易做到。如果改用我的方法，则需要重写整个项目以使用 SqlCommand 和事务。

• 对命令级别的轻微修改将需要从我的方法转向标准 SqlCommand。例如，当仅查询一行时，必须扩展 DataAccess 类以包含这种情况，或者代码必须直接使用 SqlCommand 和 ExecuteReader(CommandBehavior.SingleRow) ) 相反。

• 可能会有小的性能损失（我还没有精确的指标）。

这种方法的其他弱点是什么，特别是对于 DataAccess.ReadManyRows？

Answer 1

你想要完成的事情很好，我实际上喜欢这种语法，而且我认为它非常灵活。不过我相信您需要更好地设计 API。

代码可读且几乎漂亮，但很难理解，主要是因为除非您确切知道每种类型的含义，否则大量泛型没有多大意义。我会尽可能使用泛型类型推断来消除其中的一些。为此，请考虑使用泛型方法而不是泛型类型。

一些语法建议（我现在没有编译器，所以它们基本上是想法）：

使用匿名类型而不是字典

编写一个将匿名类型转换为字典的帮助器很简单，但我认为它改进了符号大大，你不需要编写new Dictionary。

使用 Tuple.Create

创建此静态方法是为了避免显式指定类型。

围绕 DataReader 创建强类型包装器

这将消除周围那些丑陋的转换 - 实际上，您真的需要访问该 lambda 中的 DataReader 吗？

我将通过示例代码来说明这一点。
感谢 David Harkness 的链接想法。

var tuples = new DataAccess ("select ProductId, AvailableQuantity from Shop.Product where ShopId = @shopId")
    .With (new { shopId = this.Shop.Id }) // map parameters to values
    .ReadMany (row =>
         Tuple.Create (row.Value<int> ("ProductId"), row.Value<int> ("AvailableQuantity"))); 

var strings = new DataAccess ("select distinct ProductName from Shop.Product")
    .ReadMany (row => row.Value<string> ("ProductName")); 

我还可以看到它被扩展用于处理单行选择：

var productName = new DataAccess ("select ProductName from Shop.Product where ProductId = @productId")
    .With (new { productId = this.SelectedProductId }) // whatever
    .ReadOne (row => row.Value<string> ("ProductName")); 

这是 Row 类的草稿：

class Row {
    DataReader reader;

    public Row (DataReader reader)
    {
        this.reader = reader;
    }

    public T Value<T> (string column)
    {
        return (T) Convert.ChangeType (reader [column], typeof (T));
    }
}

它将在 ReadOne 和 ReadMany 内实例化code> 调用并为选择器 lambda 提供对底层 DataReader 的便捷（且有限）访问。

Answer 2

我的想法：您将 SQL 嵌入代码、字符串中（而不是使用 LINQ，LINQ 至少经过语法检查，这有助于您保持 DBML 或 EDMX 映射文件与数据库结构同步）。以这种方式将 SQL 嵌入到未经语法检查的代码中很容易导致代码无法维护，您（或其他人）稍后会以破坏应用程序的方式更改数据库结构或嵌入的 SQL 字符串。在字符串中嵌入 SQL 特别容易产生难以发现的错误，因为有逻辑错误的代码仍然可以正确编译；这使得不太熟悉代码库的开发人员更有可能获得一种错误的安全感，认为他们所做的更改没有产生任何不利或意外的影响。

Answer 3

你的抽象方法看起来不错。由于额外的方法调用而造成的任何性能损失都是微不足道的，而且开发人员的时间比 CPU 时间要昂贵得多。当您需要添加事务或单行选择时，您可以扩展您的库类。您在这里很好地利用了不要重复自己。

Spring Framework for Java 大量使用这些类型的模板类和帮助器（例如 JdbcTemplate 和 HibernateTemplate），以消除开发人员编写样板代码的需要。这个想法是编写并测试一次并多次重用它。

Answer 4

首先，永远不要因为没有复制粘贴代码而道歉。

您的抽象看起来不错，但是更让我困扰的是您给出的第一个示例使 SqlConnection 保持打开的时间比需要的时间长。

使用 IEnumerable 非常棒，因为您可以将执行推迟到何时以及是否被消耗。
但是，只要您尚未到达枚举末尾，连接就会保持打开状态。

您的方法的实现可以通过 ToList() 消耗整个枚举，然后返回列表。您甚至可以通过实现一个小型自定义枚举器来支持延迟执行。

但我需要对此提出警告，验证在枚举时没有任何旧代码执行一些魔法。

Answer 5

对于刚接触这种方法的人来说，委托确实让立即阅读/理解有点困难，但最终应该很容易掌握。

从可维护性的角度来看，当错误最终蔓延时，理解堆栈跟踪可能会更困难。主要是如果本节中发生错误：

new DataAccess<string>.Yield(
    dataReader =>
    {
        return new Tuple<int, int>(
            (int)dataReader["ProductId"],
            Convert.ToInt32(dataReader["AvailableQuantity"]);
    }));

yield 的使用对您可以尝试/捕获的位置施加了一些限制（为什么yield return不能出现在带有a的try块内catch？），但这也是之前方法中的一个问题，可能与您的场景无关。