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

Question

通常，我使用包含以下内容的解决方案开始了新项目：

• Web项目：包含ASP.NET MVC或Web API控制器，Javascript代码等。对类库进行调用

• 类库1 ：包含DbContext，EF数据模型，具有CRUD方法以通过DbContext与Db进行接口的类以及各种“实用程序”方法< / p>

• 类库2 ：仅包含POCO类。 Web项目和library1都引用了该库。

好的，这很好，但是当“业务逻辑”的数量开始增加时，这有点混乱，因为我开始输入业务为您提供的更多规则。让我认为需要在另一个“层”或库中放置“业务逻辑”，该逻辑实际上超出/超出了仅仅作为POCO对象的过滤列表返回的数据。诸如根据业务中某个组定义的某些规则检查订单属性之类的事情。

然后我的问题是：即使在仅需要某种形式的简单查找值列表的简单情况下，您是否也会迫使来自客户端层的每个调用都经过业务库（请参见案例2下的图像）？

Answer 1

这个问题很可能会引起有根据的答案。我的看法是-是的，我会强迫所有内容都通过业务库。

要真正具有一致性，可以确保：

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

现在-这并不是说它不会变得复杂，而是会变得复杂。但是，还有其他一些方法可以拆分事物，您不一定需要有一个巨大的DBContext类来处理N个不同的查询，具体取决于我们的设计，我们最终可能会使用部分类将其拆分因此，不同的功能最终会存储在不同的文件中，它们的测试也将映射到不同的文件；我们认为这可以改善整体可维护性。