使用DAAB 3.5 / 4.0的DAL设计

Question

我正在使用.Net 3.5 Web应用程序。它具有各种模块，例如客户，订单等。我需要使用Enterprise Library 4.0（使用数据访问）来设计相同的数据访问层（DAL）。应用程序块或DAAB）以连接到SQL Server2005。这是我计划进行的工作：

•有一个名为“ IDataService”的接口。它将具有诸如“ ExecuteReader（）”，“ ExecuteScalar（）”，“ ExecuteNonQuery（）”，“ AddParams”等成员，基本上，该接口看起来将类似于DAAB。

•具有一个名为“ DataService”的类，该类实现了此接口。此类将充当DAAB的包装，并且每个方法将在内部使用DAAB中的相应方法。

•具有业务类（或数据容器），如客户，数据等，这些类将具有映射到数据库中相应表属性的属性。

•每个模块都有DAL类，例如CustomerDataService，OrdersDataService等。这些类中的每一个都将具有构造函数代码，在其中将实例化DataService类，如下所示：IDataService dataService = new DataService（）此外，这些类中的每一个将具有类似的方法： GetCustomerDetails（）AddCustomer（）RemoveCustomer（）UpdateOrder等。这些方法将在内部使用“ dataService”对象对数据库执行任何操作ExecuteReader，ExecuteNonQuery等

•为每个模块（例如“ CustomerMapper”，“ OrderMapper”等）都有一个映射器类。 这些类将数据源（例如IDataReader）作为输入，并将数据填充到通用集合（列表）中。 这些映射器类将由相应的Dataservice类在内部调用，以将类型安全的集合返回给调用客户端。

•有一个类似DbHelper的帮助程序类，它将执行诸如“处理DBNull情况”，“存储存储过程名称”等任务。

•DataService类将由BusinessLogic层类依次使用...即CustomerBusiness，OrdersBusiness等。

•业务逻辑层将集合返回到表示层。

这种设计有意义吗？这种方法的优点/缺点是什么？ 我可以想到的这种方法的优点是，所有DataService类都将始终针对“ IDataService”接口进行编程，而无需知道内部如何实现“ DataService”类。因此，将来，如果我删除DAAB并在内部使用另一个API DataService类，不需要更改客户端代码。 另外，我可以在IDataService接口中添加DAAB中不存在的任何方法。...例如BatchUpdate（）...

如果我错了，请纠正我。

Answer 1

看起来您正在使它变得比应有的复杂。 也许一次采取一个步骤会有所帮助。

DAL：我看不到DAAB有包装纸的好处。 IMO，DAAB已经是DAL包装器。 包装上的包装适得其反。 应该只有一个DAL。 这就是DAL的重点。

ORM：对于mapper类，也许您应该考虑使用Entity Framework或NHibernate for ORM。 模式发展时，编写自己的ORM既繁琐又难于维护。