使用DAAB 3.5/4.0进行DAL设计

Question

我正在开发一个.Net 3.5 web application.It，它有各种模块，例如客户、订单等。我需要使用Enterprise Library 4.0 (使用数据访问应用程序块或DAAB)来连接到SQL Server 2005来设计数据访问层(DAL)。下面是我的计划：

·有一个名为“IDataService”的接口，.It会有像"ExecuteReader()"，"ExecuteScalar()"，"ExecuteNonQuery()"，"AddParams"，etc...basically这样的成员，这个接口看起来就像DAAB一样。

·有一个名为"DataService“的类，它实现了这个interface.This类，它将充当DAAB上的包装器，每个方法都将在内部使用DAAB中的相应方法。

·拥有业务类(或数据容器)，如Customer、Data等，这些业务类的属性将映射到数据库中相应的表属性。

·为每个模块创建DAL类，如CustomerDataService、OrdersDataService、etc.Each这些类将具有构造函数代码，我将在其中实例化DataService类，如下所示: IDataService dataService= dataService= DataService()另外，这些类中的每个类都将具有如下方法: GetCustomerDetails() AddCustomer() RemoveCustomer() UpdateOrder等。这些方法将在内部使用"dataService“对象对数据库ExecuteReader、ExecuteNonQuery等进行任何操作。

·为每个模块创建一个映射器类，如"CustomerMapper“、"OrderMapper”等。这些类将接受数据源(例如IDataReader)作为输入，并填充通用集合(List)中的数据。这些映射器类将由相应的Dataservice类在内部调用，以将类型安全集合返回给调用客户端。

·有一个像DbHelper这样的帮助器类，它将执行“处理DBNull案例”、“存储存储过程名称”等任务。

·DataService类将依次由BusinessLogic layer classes...ie CustomerBusiness、OrdersBusiness等使用。

·业务逻辑层将集合返回给表示层。

这种设计有意义吗?这种方法的优点/缺点是什么？我认为这种方法的优点是，所有的DataService类都将始终针对接口"IDataService“进行编程，而不需要知道" DataService”类是如何在将来实现internally.So的，如果我删除DAAB并在DataService类中使用另一个API，则客户端代码不需要更改。此外，我还可以在我的IDataService接口中添加DAAB....for示例BatchUpdate()中没有的任何方法...

如果我错了，请纠正我。

Answer 1

看起来你把事情搞得太复杂了。也许一步一步来会有帮助。

DAL:我看不出在DAAB上使用包装器有什么好处。IMO，DAAB已经是一个DAL包装器了。包装器高于包装器是适得其反的。应该只有一个DAL。这就是DAL的意义所在。

ORM:对于映射器类，也许您应该考虑使用实体框架或NHibernate。当模式演变时，编写自己的ORM是单调乏味的，而且很难维护。