我正在研究.Net 3.5网络应用程序。它有各种模块，例如客户，订单等......我需要使用Enterprise Library 4.0来设计数据访问层（DAL）（使用数据访问应用程序块或DAAB）连接到SQL Server 2005.以下是我计划如何去做：
•有一个名为“IDataService”的接口。它会有“ExecuteReader（）”，“ExecuteScalar（）”，“ExecuteNonQuery（）”，“AddParams”等成员...基本上，这个界面几乎看起来像DAAB那样。
•有一个名为“DataService”的类，它实现了这个接口。这个类将充当DAAB的包装器，每个方法都将在内部使用DAAB中的相应方法。
•拥有Business，Data等业务类（或数据容器），这些类将具有映射到数据库中相应表属性的属性。
•拥有每个模块的DAL类，如CustomerDataService，OrdersDataService等。这些类中的每一个都将具有构造函数代码，我将在其中实例化DataService类，如下所示：IDataService dataService = new DataService（）此外，每个类都将具有方法如：GetCustomerDetails（）AddCustomer（）RemoveCustomer（）UpdateOrder等。这些方法将在内部使用“dataService”对象对数据库ExecuteReader，ExecuteNonQuery等进行任何操作
•为每个模块设置一个映射器类，如“CustomerMapper”，“OrderMapper”等。这些类将数据源（例如IDataReader）作为输入，并将填充泛型集合（List）中的数据。这些映射器类将由相应的Dataservice类在内部调用，以将类型安全的集合返回给调用客户端。
•有一个像DbHelper这样的辅助类，可以执行“处理DBNull情况”，“存储存储过程名称”等任务。
•BusinessLogic类将由BusinessLogic层类使用，即CustomerBusiness，OrdersBusiness等。
•业务逻辑层将集合返回到表示层。
这种设计有意义吗？这种方法有哪些优点/缺点？我能想到这种方法的优点是，所有DataService类都将始终针对“IDataService”接口进行编程，而无需知道如何在内部实现“DataService”类。所以在将来，如果我删除DAAB并在我的内部使用另一个API DataService类，客户端代码无需更改。 另外，我可以在我的IDataService接口中添加DAAB中不存在的任何方法....例如BatchUpdate（）......
如果我错了，请纠正我。
答案 0 :(得分：0)
看起来你让它变得比它应该复杂。也许一步一步就会有所帮助。
DAL： 我没有看到在DAAB上使用包装器的好处。 IMO，DAAB已经是DAL包装器了。封装器上的包装是适得其反的。应该只有一个DAL。这是DAL的重点。
ORM： 对于mapper类，也许您应该考虑使用Entity Framework或NHibernate进行ORM。在架构发展时，编写自己的ORM代码很繁琐且难以维护。