Question

对此的背景故事是同事不喜欢我们在企业库数据访问块上的标准化，因为

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

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

为什么Enterprise Library或其他数据库抽象层没有为基本类型提供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。

另一个含义是，如果我想模拟数据库类，我现在有一个巨大的重载接口，我需要实现而不只是一个。

我的另一个大问题是......

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

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不提供该功能。

第二个问题：

DbCommands是特定于数据库提供程序的，因此您需要一个工厂方法来实例化它们。

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

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

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

Answer 2

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

企业库数据访问阻止设计决策

2 个答案: