我正在开发一个 .Net 3.5 Web 应用程序。它有各种模块，例如客户、订单等。我需要使用 Enterprise Library 4.0 设计数据访问层 (DAL)（使用数据访问应用程序块或 DAAB）连接到 SQL Server 2005。这是我打算如何去做：
• 有一个名为“IDataService”的接口。它将有“ExecuteReader()”、“ExecuteScalar()”、“ExecuteNonQuery()”、“AddParams”等成员......基本上，这个接口几乎看起来像达布。
• 有一个名为“DataService”的类，它实现了这个接口。这个类将充当DAAB 的包装器，每个方法都将在内部使用DAAB 中的相应方法。
• 拥有像客户、数据等这样的业务类（或数据容器），它们的属性将映射到数据库中相应的表属性。
• 每个模块都有 DAL 类，如 CustomerDataService、OrdersDataService 等。这些类中的每一个都有构造函数代码，我将在其中实例化 DataService 类，如下所示： IDataService dataService= new DataService() 此外，这些类中的每一个都有如下方法： GetCustomerDetails() AddCustomer() RemoveCustomer() UpdateOrder 等这些方法将在内部使用“dataService”对象对数据库 ExecuteReader、ExecuteNonQuery 等进行任何操作
• 每个模块都有一个映射器类，如“CustomerMapper”、“OrderMapper”等。这些类将数据源（例如 IDataReader）作为输入，并将数据填充到通用集合（List）中。并且这些映射器类将由相应的 Dataservice 类在内部调用，以将类型安全的集合返回给调用客户端。
• 有一个像DbHelper 这样的帮助类，它会执行诸如“处理DBNull 案例”、“存储存储过程名称”等任务。
• DataService 类将被BusinessLogic 层类依次使用……即CustomerBusiness、OrdersBusiness 等。
• 业务逻辑层将集合返回到表示层。
这种设计有意义吗？这种方法的优点/缺点是什么？我能想到这种方法的优点是所有 DataService 类将始终针对接口“IDataService”进行编程，而无需知道“DataService”类是如何在内部实现的。因此，将来，如果我删除 DAAB 并在我的内部使用另一个 API DataService 类，客户端代码无需更改。此外，我可以在我的 IDataService 接口中添加 DAAB 中不存在的任何方法....例如 BatchUpdate()...
如果我错了，请纠正我。