C# 使用MVC+；存储库模式，业务逻辑应该在哪里？

我想知道关于它的正确概念。如果我有一个具有存储库模式的MVC应用程序，那么BL应该在哪里

• 它应该在模型内部吗？模特应该拥有所有的生意 调用unitofwork之前的逻辑，以插入或不插入数据 数据库

• 它应该在控制器中吗？在打电话给模特之前

• 我是否应该有一个服务层来执行业务逻辑并决定 我应该调用模型来调用UnitOfWork来保存数据

---

一个好的解释也会有很大帮助。

简短的答案——视情况而定。若它是一个相当复杂或规模相当大的应用程序，我喜欢创建一个以存储库作为依赖项的服务层项目。如果它是一个小应用程序，我将把逻辑放在控制器中。在我看来，如果创建服务层比创建应用程序（即一个或两个控制器）需要更多的时间和精力，那么对我来说，这样做没有意义。您还需要考虑应用程序将增长的可能性。一开始可能很小的东西可能会发展成更大的东西，在这种情况下，创建单独的服务层可能更有益

第三个。。。然后是一些

您的应用程序结构可能如下所示（在不同的项目中）：

• 数据存储层（如SQL数据库）
• ORM（例如NHibernate或实体框架）
• 域（包括抽象存储库和实体）
• 服务层（可选业务层）
• MVC应用程序（具有与实体相关的自己的模型）

但是，根据应用程序的复杂性和大小，有很多方法可以做到这一点。

这个问题没有“正确”的答案，它主要是基于观点的。您可以在以下项目wiki中阅读我的观点：

---

我想提供的另一条建议是，永远不要在viewmodels或实体中放置任何业务逻辑。这些类不应该有方法，而应该只有包含数据的属性。将数据与行为分开。对数据使用模型，对行为（方法）使用其他类型。

这是最好的答案。控制器应该是精简的-它们的主要目的是选择正确的视图并在视图和模型之间传输数据。如果您的应用程序很小或很简单（搜索、只读等），那么只需将该逻辑放入控制器中即可。在您的控制器所做的不仅仅是促进对视图的数据传输，然后您应该考虑创建服务层。有时最好的解决办法是保持简单。仅仅因为创建服务层是解决1000美元问题的百万美元解决方案。@Matty-M谢谢！！因此，如果我有一个服务层，服务层是否应该有一个Insert/Update/Delete方法，其中包含一个UnitOfWork？或者它里面的一个模型，叫做工作单元？@LeandroDeMelloFagundes，这就是我在服务层所做的。存储库本身将处理crud操作，但我在服务层中有类似的命名方法，这些方法处理任何业务逻辑，并在必要时创建工作单元并将其传递给存储库（在无法注入UOW的情况下）。@MattyM那么，您的模型没有任何类型的方法吗？只有表示表列的属性？插入/更新/删除不在您的模型中，对吗？很抱歉问了这么多问题，但我真的想知道更好的开始方式：）