我需要设计一个数据访问层DAL .Net Enterprise库版本3.5数据访问应用程序块（DAAB） 在我的应用程序中，我有各种逻辑模块，如注册，计费，订单管理，用户管理等 我使用C＃业务实体将模块对象映射到数据库表，然后将List集合返回给客户端。
我想以这样的方式设计我的DAL：如果明天我们决定使用其他一些数据访问框架，那么我们应该尽量减少代码更改。 鉴于此，我如何设计我的类结构？ 我以为我会有一个类DbManagerBase，它将是现有.net DAAB的包装器 这个类DbManagerBase将实现一个名为IDbManagerBase的接口，该接口将具有ExecuteReader，ExecuteNonQuery等公共方法。
客户端类即。 RegistrationDAL，UserManagermentDAL在其每个方法中都有以下代码： IDbManagerBase obj = new DbManagerBase（） obj.ExecuteReader（myStoredProcName） 。 。 。 这是一个很好的OOPS设计吗？我可以知道任何更好的方法吗？或者我需要在这里使用继承吗？ 我可以将DbManagerBase类和RegistrationDAL中的所有方法，UserManagermentDAL类作为静态吗？我猜，如果我的方法是静态的，那么上面的接口代码就没有任何意义......对吧???
答案 0 :(得分：4)
要真正抽象DAL我会使用repository pattern。
答案 1 :(得分：2)
回答几个问题：
我可以使用所有方法吗？ DbManagerBase类和 RegistrationDAL，UserManagermentDAL 类是静态的？
我可能采用非静态方法，因为它可以灵活地更好地控制DAL的实例化（例如，你可以从工厂创建它们的实例），也可以让你有两个DAL到位那些以更清洁的方式与不同的DB交谈。此外，您不需要在每个对象中创建DbManagerBase的实例，因为它将是实例成员。
关于IDbManagerBase有ExecuteReader，ExecuteNonQuery和obj.ExecuteReader（myStoredProcName）
我会在太多地方烘焙有关数据库特定概念的知识。请记住一些DB不支持存储过程。
另一点是，在我开始实现DAL之前，我一定会阅读其他开源DAL中的一些代码，如NHibernate或Subsonic。它们完全有可能解决您的业务问题并显着减少您的开发时间。
如果您正在寻找分层DAL架构的一个小例子，那就是我的little project on github（这是非常基本的，但展示了如何构建接口以支持许多深奥的数据库）