ASP.NET MVC:BLL 和 DAL 到存储库设计
我们正在从 ASP.NET Web 窗体迁移到 MVC 2.0。在我们的大多数项目中,我们都有一个典型的设置来与数据库进行通信。
通用(“SiteMenu”和“用户”等对象/实体)
业务逻辑层(调用数据访问层)
数据访问层
DAL 有一个具有通用数据库操作的DatabaseHelper、一个具有数据库特定操作(例如MySQL)的OdbcHelper 和一个具有所有存储过程的StoredProcedure 类。
这个设计如何转化为存储库设计?我们想使用我们自己的数据库助手而不是 NHibernate 等。
您有什么建议?
We are moving from ASP.NET Web Forms to MVC 2.0. In most of our projects we have a typical setup to communicate with a database.
Common (objects/entities like 'SiteMenu' and 'Users')
Business Logic Layer (with calls to de Data Access Layer)
Data Access Layer
The DAL has a DatabaseHelper with common database operation, an OdbcHelper with database specific operations (eg MySQL) and a StoredProcedure class with all the stored procedures.
How is this design translated into a repository design? We want to use our own database helpers instead of NHibernate etc.
What would you suggest?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以使用各种数据访问技术来利用存储库。
存储库是对现有数据访问帮助程序/服务的抽象,允许将业务逻辑与数据访问层解耦。存储库与查询一起使用以启用过滤。它通常与工作单元一起使用,将更改存储回数据库。
存储库至少具有:
非常简单示例 :):
A. Product 类,在 Common 中定义:
B. Query、IRepository 和 类strong>IUnitOfWork 在DAL.interfaces.dll 或Common.dll 中定义(但不在DAL 中!)。
IUnitOfWork 知道更改的实体。 Save() 为每个更改的实体调用适当的 DatabaseHelper / OdbcHelper CRUD 方法,以便将更改保留在数据库中。
IRepository、...IRepository 和 IUnitOFWork 的实现应放置在 DAL 中。然后,BLL 使用IRepository 和IUnitOFWork 来实现业务(域)逻辑。 BLL 本身可以组织为域模型之上的服务层,但这超出了讨论范围:)。
希望我的回答有帮助。
请随时问我问题...
链接:
Martin Fowler 的企业应用程序架构模式
You could leverage repositories using every data access technology.
An repository is abstraction over existing data access helpers / services, allowing decoupling of the business logic from the data access layer. Repositories used together with Query to enable filtering. It is often used together with unit of work to store the changes back into database.
A repository has at least:
A very simple example :):
A. Product class , defined in Common:
B. Classes for Query, IRepository and IUnitOfWork are defined in DAL.interfaces.dll or Common.dll (but NOT in DAL!).
IUnitOfWork is aware of the changed entities. Save() calls an appropriate DatabaseHelper / OdbcHelper CRUD method for every changed entity in order to persist the changes in the database.
The implementation of IRepository<Product>, ... IRepository<EntityXY> and IUnitOFWork should be placed in DAL. The BLL then uses IRepository and IUnitOFWork in order to implement business (domain) logic. The BLL itself could be organized as service layer on the top of domain model, but it is out of the scope of the discussion :).
I hope my answer helps.
Please feel free to ask me a question ...
Links:
Patterns of enterpise application architecture by Martin Fowler
当迁移到 MVC 时,您可以保持相同的分层方法。返回实体/对象的 BLL 可以是 MVC 中的 M。通常,您会在示例中看到人们直接在其控制器中创建存储库的实例,在您的情况下,您将创建 BLL 类的实例。
You can maintain the same layered approach when moving to MVC. Your BLL that returns entities/objects can be your M in MVC. Often you'll see in samples where people create an instance of the repository directly in their Controller, in your case you'll be creating an instance of your BLL class.