将域的 BALL 包装到它自己的类库中是否合理，我将如何设置它？

Question

我多次听说将您的 DAL 放入类库中。这是有道理的，我想这样做是为了减少跨应用程序的代码重复。我决定使用实体框架来构建该 DAL。

然而，根据我对 N 层应用程序的了解，DAL 实际上只是要公开 POCO 类，我将把它当作 DTO 对待。为方便起见，我的 DAL.dll 将公开 EmployeeDto 之类的类和 GetEmployeeDtoByID(int ID) 之类的方法，以明确这一层不会生成最终的域模型。

但是，如果我想要一个生成最终域模型的可重用 DLL，该怎么办？能够创建一个新项目、添加 CompanyBLL.dll 引用并开始调用GetAllEmployees 知道这里公开的类是该对象的域模型的真实表示，这肯定会很好。从本质上讲，我所做的每个项目都只是为所需的不同工具提供了一个新的表示层。

我知道这些是我在开始部署 N 层应用程序时应该做出的个人选择，但这是一个合理的目标吗？如果是这样，我是否制作 DAL.dll，并且仅在构建 BLL 类库时才真正引用它？将它们组合到一个单一的类库中会更有意义吗？

我只是不确定我是否因为不想为我制作的每个应用程序重建业务逻辑而疯狂，以及这是否是正确的方法。

Answer 1

我会推荐这种架构。

Presentation -> BLL -> Repository -> EF -> Db

您的存储库返回 EF 负责的实体集合。

您的repository 的职责是执行CRUD operations。它在内部使用 EF，但您的 BLL 或 presentation 不需要知道这一点。