企业库数据访问块设计决策答案

【问题标题】：Enterprise Library Data Access Blocks Design Decisions企业库数据访问块设计决策
【发布时间】：2009-07-17 11:09:17
【问题描述】：

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

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

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

我的另一个大问题是..

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

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);

我很想看看你们的想法。

谢谢

【问题讨论】：

标签： c# database enterprise-library

【解决方案1】：

第一个问题：

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

第二个问题：

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

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

如果 Database 对象存储了隐式 DbCommand，则无法再跨线程共享 Database 实例。

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

【讨论】：

【解决方案2】：

请注意，Enterprise Library Data Access Blocks 不是一个新的数据访问框架，它是普通 ADO.NET 的包装器，它自动为您提供大型企业应用程序所需的许多东西。所以它只节省了一些代码行。背后的技术仍然是简单的 ADO.NET。那么请您提供有关您的问题的更多信息吗？据我所知，您根本不喜欢 Enterprise Library Data Access Blocks 的 API 语法。

【讨论】：