在 Web 应用程序中分离 BLL、PL 和 DAL
我负责开发一个可以有多个表示层的 Web 应用程序,目前它在 Web 上,但很快就会出现在桌面和其他平台上。所以我四处寻找如何做得最好。我发现最好使用分层方法。
我正在考虑将 BLL 作为一项网络服务,可以由不同的 PL 访问。 BLL 将访问 DAL 以进行数据特定操作。 到目前为止一切顺利,但我正在考虑将 ASP.NET MVC 用于 Web 应用程序。现在我有点困惑,因为“控制器”本质上包含业务逻辑,对吧。 这是一个好的选择吗?如果我确实遵循相同的路径,使用 MVC 和上述层,我的控制器不一定包含 BLL,而只是有点虚拟。
这是正确的做法吗?
I have been given to develop a web application that can have multiple presentation layers, currently its on the web but soon to be on desktops and other platforms. So I searched around on how to do it best. I have found that its better to use a layered approach.
I am thinking to have BLL as a web-service which could be accessed by different PLs. The BLL will be accessing DAL for data specific operations.
So far so good, but I was thinking of using ASP.NET MVC for the web app. Now I am a bit confused because the "controllers" essentially contain the business logic, right.
Is it a good option ? If i do follow the same path, using MVC and the above mentioned layers, my controllers wont necessarily contain the BLL but will only be, kinda dummies.
Is it the right way to do it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这些是推荐的层:
演示(MVC、WPF 等):
仅包含表示逻辑(从不包括业务逻辑),控制器仅处理与应用程序/服务层的通信以协调通信。
分布式服务(远程外观):
由于您将拥有许多客户端,其中一些是 Windows 应用程序,另一些是 Web 应用程序,因此建议创建一个远程服务层(WCF 服务或 Web 服务),向消费者公开业务层(最好是发送和接收 DTO)。
应用层:
该层处理与域层的通信,并协调事务逻辑和技术服务,如果您使用 DTO,它会将域对象转换为 DTO,反之亦然
域层:
包含实体和值对象,这是业务逻辑的核心,按照面向对象的领域对象封装数据和逻辑来设计。如果使用存储库模式,它还可以包含存储库接口。以及不适合单个实体的逻辑的域服务。
数据访问:
使用 NHibernate 或 EF 等 ORM 或任何数据访问技术将实体映射到数据库表中。
基础设施/通用:
基础设施代码和横切技术服务(例如日志记录)
我将尝试举一个关于每一层的小例子:
一个假设的不完整示例,假设您要激活采购订单
表示层 (MVC):
分布式服务层(Web 服务):
应用程序层:
域层:
存储库(数据访问层):
基础设施:
These are the recommended layers:
Presentation (MVC, WPF, Whatever):
contains only presentation logic (never includes business logic) the controller only handle communication with application/services layer to co-ordinate communication.
Distributed Services (Remote Facade):
as you will have many clients, some of them would be windows apps and others are web apps, it is recommended to create a remote service layer (WCF services or web services) which exposes business layer to consumers (preferable send and receive DTOs).
Application Layer:
a layer which handles the communication with domain layer, and co-ordinate transaction logic and technical services, and if you are using DTOs it translates domain objects into DTOs and vice versa
Domain Layer:
contains entities and value objects, this is the core of business logic designed in terms of object oriented domain objects encapsulating data and logic. it also could contains repository interfaces if using repository pattern. and domain services for logic that does not fit into a single entity.
Data Access:
using ORM like NHibernate or EF or whatever data access techniques to map entities into database tables.
Infrastructure / Common:
infrastructure code and cross cutting technical services like logging
I will try to give a tiny example about each layer:
a hypothetical incomplete example say you want to activate a purchase order
Presentation Layer (MVC):
Distributed Service Layer (Web Service):
Application Layer:
Domain Layer:
Repositories (Data Access Layer):
Infrastrucute: