使用 MVC + Repository 模式，业务逻辑应该在哪里？答案

【问题标题】：Using MVC + Repository Pattern, where Business Logic should be?使用 MVC + Repository 模式，业务逻辑应该在哪里？
【发布时间】：2015-01-22 12:44:11
【问题描述】：

我想知道关于它的正确概念。如果我有一个带有 Repository Pattern 的 MVC 应用程序，那么 BL 应该在哪里？

它应该在模型内部吗？模型应该有所有的业务调用 unitofwork 将数据插入或不插入之前的逻辑数据库？
应该在控制器中吗？在调用模型之前？
我是否应该有一个服务层来处理业务逻辑并决定是否我应该调用Model调用UnitOfWork来保存数据吗？

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

【问题讨论】：

标签： c# asp.net-mvc-4 repository-pattern unit-of-work business-logic

【解决方案1】：

简短的回答 - 视情况而定。如果它是一个相当复杂或相当大的应用程序，我喜欢创建一个服务层项目，并将存储库作为依赖项。如果是小型应用程序，我会将逻辑放在控制器中。在我看来，如果创建服务层比创建应用程序（即一个或两个控制器）花费更多的时间和精力，那么我走这条路没有意义。您还需要考虑应用程序增长的可能性。最初可能很小的东西可能会发展成更大的东西，在这种情况下，再次创建单独的服务层可能会更有益。

【讨论】：

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

【解决方案2】：

第三个......然后是一些。

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

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

但是有很多方法可以解决这个问题，具体取决于应用程序的复杂性和大小。

【讨论】：

【解决方案3】：

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

https://github.com/danludwig/tripod/wiki/Why-Tripod%3F

https://github.com/danludwig/tripod/wiki/Dependency-and-Control-Inversion

https://github.com/danludwig/tripod/wiki/Tripod-101

https://github.com/danludwig/tripod/wiki/Testing,-Testing,-1-2-3

https://github.com/danludwig/tripod/wiki/Command-Query-Responsibility-Segregation-(CQRS)

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

【讨论】：