c# - 企业图书馆数据访问 block 设计决策

Question

这背后的故事是一位同事不喜欢我们在企业库数据访问 block 上标准化的事实，因为

• 在每个需要数据库访问的项目中都需要太多引用
• 我们不需要它提供的所有功能
• 他认为 DbCommand/SqlCommand 应该存储在数据库对象内部，而不是让数据库构建一个 sqlcommand 并要求用户在外部管理其状态
• 他不喜欢你在添加参数时必须指定类型，他认为重载应该为你推断类型。*不喜欢 Enterprise Library 对所有数据库都是通用的，而我们的系统显然只会与 Sql Server 兼容

我个人想继续使用企业库而不是他自己开发的解决方案，但这确实让我提出了一些问题。

为什么企业库或其他数据库抽象层不为基本类型提供 AddParameter 重载？

例子

   db.AddInParameter(dbCommand, 
     "EmployeeID", DbType.Int32, 1);

他们不只是为所有数据类型(如 int)提供重载，而不是只获取一个对象并强制用户指定类型的原因是什么，或者某些原因。

   db.AddInParameter(dbCommand, "EmployeeID", 1);

我能想到的一些原因是......

如果您没有将每个类型映射都指定为重载，则可能会发生以下情况。

假设您对 int 有重载但对 char 没有重载

char c = 'R'

db.AddInParameter(dbCommand, "Initial", c);

编译器会将重载解析为 int 而不是 char 并抛出错误，因为存储过程期望类型为 char。

另一个含义是，如果我想模拟数据库类，我现在需要实现大量的重载接口(interface)，而不仅仅是一个。

我的另一个大问题是..

为什么数据访问 block 要求您检索命令对象，然后将其传回以供后续调用，而不是仅仅在内部管理其状态？

using (var cmd = db.GetStoredProcCommand("AddEmployee"))
{
      db.AddInParameter(cmd, "@Name", DbType.String, name);

代替

using(var db = new Database())
{

      db.CreateStoredProcCommand("AddEmployee")

      db.AddInParameter("@Name", DbType.String, name);

我很想知道你们是怎么想的。

谢谢

Answer 1

第一个问题:

这只是一个猜测，但我怀疑这是因为 ADO.NET 没有提供该功能。

第二个问题:

DbCommand 是特定于数据库提供者的，因此您需要在某处使用工厂方法来实例化它们。

至于将命令及其参数存储在数据库对象中，数据库对象被设计为不包含特定于命令的状态。这使它们能够被重复使用。一种常见的模式是在应用程序启动时实例化一个数据库对象，并在应用程序的生命周期中根据需要调用它的 GetXXXCommand() 方法。此外，多线程应用程序(例如网站)可以从单个数据库对象安全地实例化 DbCommand，即使在处理许多并发请求时也是如此。

如果数据库对象存储隐式 DbCommand，数据库实例的跨线程共享将不再可能。

最后，即使在单线程应用程序中，也完全有可能构造多个 DbCommand，或者在调用 GetXXXCommand() 和调用 ExecuteXXX() 之间没有一对一的映射。例如，您可以多次执行它们，每次使用不同的参数。