DAL设计问题
我需要设计一个数据访问层 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 类中的所有方法都设置为静态吗？我猜，如果我将方法设置为静态，那么上面的接口代码将没有任何意义...对吧？？？
I need to design a Data access layer DAL .Net Enterprise library version 3.5 Data access application block (DAAB)
In my application,I've various logical modules like Registration, billing, order management, user management,etc
Am using C# business entities to map the module objects to database tables and then return the List collection to the client.
I would like to design my DAL in such a way that if tomorrow we decide to use some other data access framework we should have minimal code change.
Given this, how do i design my class structure?
I thought I would have a class DbManagerBase which would be a wrapper over existing .net DAAB
This class DbManagerBase would implement an interface called IDbManagerBase which would have public methods like ExecuteReader, ExecuteNonQuery, etc.
The client class ie. RegistrationDAL,UserManagermentDAL would have the following code inside each of its methods:
IDbManagerBase obj= new DbManagerBase()
obj.ExecuteReader(myStoredProcName)
.
.
.
is this a good OOPS design?may i know any better approach please?or do i need to use inheritance here?
Can i have all the methods in DbManagerBase class and RegistrationDAL,UserManagermentDAL classes as static?I guess,if i've methods as static then the above interface code wont make any sense...right???
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
回答几个问题：
我可能会采用非静态方法，因为它可以灵活地更好地控制 DAL 的实例化（例如，您可以从工厂创建它们的实例），而且它还允许您有两个正在通信的 DAL以更干净的方式连接到不同的数据库。 此外，您不需要在每个对象中创建 DbManagerBase 的实例，因为它是实例成员。
我会在太多地方小心地烘焙有关数据库特定概念的知识。 请记住某些数据库不支持存储过程。
另一点是，在开始实现某种 DAL 之前，我一定要通读其他开源 DAL（例如 NHibernate 或 Subsonic）中的一些代码。 他们完全有可能解决您的业务问题并显着减少您的开发时间。
如果您正在寻找分层 DAL 架构的小示例，请参阅我的 小项目在 github 上（它非常基础，但展示了如何构建接口来支持许多深奥的数据库）
To answer a few of the questions:
I would probably go with a non-static approach cause it gives the flexibility to better control instantiation of the DALs (eg. you could create instances of them from a factory), also it will allow you to have two DALs in place that are talking to different DBs in a cleaner way. Also you will not need to create an instance of the DbManagerBase in every object since it would be an instance member.
I would be careful about baking the knowledge about database specific concepts in too many places. Keep in mind some DBs to not support stored procedures.
Another point is that before I went about implementing a DAL of sorts I would be sure to read through some code in other open source DALs like NHibernate or Subsonic. It is completely possible they would solve your business problem and reduce your dev time significantly.
If you are looking for a small example of a layered DAL architecture there is my little project on github (it is very basic but shows how you can build interfaces to support a lot of esoteric databases)
为了真正抽象 DAL，我将使用存储库模式。
To truly abstract the DAL I'd use the repository pattern.