我听说过多次将DAL放入类库中。 这是有道理的,我想这样做,以便我可以减少应用程序之间的代码重复。 我决定使用实体框架来构建该 DAL。
然而,根据我对 N 层应用程序的理解,DAL 实际上只是公开 POCO 类,我将像 DTO 一样对待它们。 为了使这变得简单,我的DAL.dll将公开像EmployeeDto
这样的类和像GetEmployeeDtoByID(int ID)
这样的方法,只是为了明确这一层不会产生最终的领域模型。
但是,如果我想要一个可重用的 DLL 来生成最终的域模型,该怎么办? 能够创建一个新项目,添加 CompanyBLL.dll 引用并开始调用GetAllEmployees
,知道此处公开的类是该对象的域模型的真实表示,这肯定会很好。基本上,我制作的每个项目都变成了所需的不同工具的新表示层。
我知道这些是我在开始部署 N 层应用程序时应该做出的个人选择,但这是一个合理的目标吗?如果是这样,我是否制作了 DAL.dll,并且仅在构建 BLL 类库时才真正引用它?将它们合并到一个类库中是否更有意义?
我只是不确定我是否因为不想为我制作的每个应用程序重建我的业务逻辑而疯狂,以及这是否是正确的方法。
我会推荐这种架构。
Presentation
->BLL
->Repository
->EF
->Db
存储库返回 EF 负责的实体的集合。
repository
的责任是执行 CRUD 操作。在内部,它使用 EF,但你的BLL
或presentation
不需要知道这一点。