使用实体框架和ASP.NET时将业务逻辑放在何处

Question

通常情况下，我使用包含以下内容的解决方案启动新项目：

• ：包含ASP.NET MVC或Web控制器、Javascript代码等。调用类库。
• Class library1：包含DbContext、EF数据模型、具有CRUD方法通过DbContext和各种“实用程序”方法与Db接口的类。
• 类library2：只包含POCO类。此库由web项目和library1引用。

好的，这样做很好，但是当“业务逻辑”的数量开始增加时，这就变得有点混乱了，因为我开始加入更多的业务规则。这让我觉得需要另一个“层”或库，在那里我们放置“业务逻辑”，而不仅仅是将数据作为POCO对象的筛选列表返回。例如，根据业务中某个组定义的一些规则检查订单的属性。

那么，我的问题是:您会强迫客户端层的每个调用都通过业务库(参见案例2下面的图像)，即使在简单的情况下，您只需要某种类型的查找值的简单列表？

​

​

Answer 1

这个问题很可能会引起一些固执己见的答案。我的看法是-是的，我会强迫一切都通过商业图书馆。

要真正做到一致性比其他任何东西都要好，这样您就可以确定：

• 您的团队中的一位新成员并不试图理解为什么某些DB操作是通过与其他操作不同的层进行的。
• 当您(或其他一些开发人员)添加/删除属于与DB交互的功能时，它的位置是众所周知的。
• 当出现关于DB层/访问/查询的问题时--查找问题更简单。
• 如果您正在测试该层/方法--我们发现将所有内容放在同一个位置更方便。(可测试性肯定会增加)我们仍然将内容分散到文件中。
• 我们使用依赖注入-因此，如果您需要DB访问，您只需注入接口，为您设置连接，您就完成了。
• 根据您的设置方式，如果您单独记录与DB相关的内容(例如分别监视查询的QoS )，这还确保您不会为这些简单的查找在代码中添加所有的自定义日志。
• 使依赖链更易于管理。

这并不是说它不会变得复杂，而是。然而，还有更多的方法可以分割东西，您不一定需要有一个庞大的DBContext类来处理N个不同的查询，根据我们的设计，我们可能会用部分类来分割它，因此不同的功能最终会出现在不同的文件上，它们的测试也会映射到不同的文件；我们认为这提高了整体的可维护性。