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

后面的故事到这是一个同事不喜欢我们的企业库数据访问块标准化因为企业库数据访问块设计决策

它需要在这需要每一个项目太多引用的事实数据库访问
我们并不需要它提供的所有功能
他认为DbCommand/SqlCommand应该内部存储在数据库对象中，而不必让数据库构建一个sqlcommand并要求用户管理其状态外部
他不喜欢在添加参数时必须指定类型，他认为重载应该为您推断出类型。 *不喜欢那个企业库是通用的所有数据库，当我们的系统显然只是永远将是兼容的SQL服务器反正

我个人想使用企业库，而不是他的家溶液生长保持，但它的确让我提出了一些问题。

为什么企业库或其他数据库抽象层为基本类型提供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和因为存储过程expeected类型是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);

我希望看到你们的想法。

感谢

来源

2009-07-17 Ryu

第一个问题：

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

第二个问题：

DbCommands是数据库供应商特定的，所以你需要一个工厂方法某处实例化它们。

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

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

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

来源

2009-07-20 18:06:41

注意，企业库数据访问块是不是一个新的数据访问框架，它是正常的ADO.NET其中做了很多的东西你在大型企业应用所需的自动包装。所以它只保存一些代码行。背后的技术仍然是简单的ADO.NET。所以，请你能提供一些关于你的问题的更多信息吗？据我所见，你只是不喜欢企业库数据访问块的API语法。

来源

2009-07-17 11:22:29 Alexander

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

回答

相关问题