业务层(BLL)数据访问层(DAL)和UI之间的通用结构？

Question

我希望我的所有图层BLL,DAL和UI共享类(具体或接口).

这真的是一种不好的做法吗？

我不想从我的DAL方法返回数据表,而是返回BLL可以直接使用的对象.

我希望有一个单独的VS项目,其中包含所有层应该知道的类.

示例:我想定义一个所有层都应该知道的批次类.UI应该能够接收批次类,以便显示或使用户能够提交要处理的批次.此外,DAL应该能够使用批次类查询数据库并返回它们.另一方面,BLL应该获得这些批次并将业务规则应用到它们上.

如果这是完全错误的替代品有哪些？

Answer 1

我希望我的所有图层BLL,DAL和UI共享类(具体或接口).

这取决于什么类型的类.如果您需要它们全部访问公共域实体,那么肯定.

重要的部分是允许这些层对这些类进行的操作.您的客户端/ UI层不应该能够修改域实体(并保留它们),而无需通过某些集中式业务逻辑.这意味着您的用户界面不应该访问您的DAL,尽管它们可以共享公共实体,接口等...

一种常见的方法是这样的:

UI - > BLL - > DAL - >持久性存储(DB,文件等...)

每个层都可以访问commmon类.只要UI无法直接访问DAL,您应该没问题.你有几个选择:

• 通过服务(WCF等)访问BLL
• 将DAL和BLL放在同一个项目中并使DAL内部,这样只有BLL可以访问它

你得到的结果如下:

UI - >服务 - > BLL - > DAL - >持久存储(DB,文件等...)

我强烈推荐Martin Fowler 的企业应用程序架构模式.它将为您的应用程序分层提供良好的基础.

我不想从我的DAL方法返回数据表,而是返回BLL可以直接使用的对象.

那是个好主意.这就是ORM的想法发挥作用的地方.DAL通常知道如何与数据库通信,DAL也将知道如何将特定于数据库的结构转换为您的域模型.域实体进入和退出DAL.在DAL中,在持久化数据时,域实体将转换为特定于DB的结构.反之亦然:当BLL请求数据时,DAL会检索数据并将其转换为域enties,然后再将其传回.