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

Question

我想了解有关此问题的正确概念。如果我有一个实现Repository模式的MVC应用程序，BL（业务逻辑层）应该放在哪里？

• 它应该放在Model内部吗？在调用UnitOfWork将数据插入或不插入数据库之前，Model必须具备所有业务逻辑吗？

• 它应该放在Controller中吗？在调用Model之前？

• 我是否需要一个服务层来执行业务逻辑并决定是否应该调用Model以调用UnitOfWork来保存数据？

良好的解释也会帮助很多。

- Leandro De Mello Fagundes

Answer 1

简短回答 - 这取决于具体情况。如果是一个相当复杂或庞大的应用程序，我会创建一个服务层项目，并将存储库作为依赖项。如果是一个小型应用程序，我会将逻辑放在控制器中。在我看来，如果创建服务层所需的时间和精力比创建应用程序（即一个或两个控制器）更多，那么对我来说这种做法就没有意义。您还需要考虑应用程序增长的可能性。可能从小开始，但可能会变得更大，在这种情况下，再次创建单独的服务层可能更有益。

- Matt M

---

这是最好的答案。控制器应该尽量精简 - 它们的主要目的是选择正确的视图并在视图和模型之间传输数据。如果您的应用程序很小或很简单（例如搜索、只读等），那么就将该逻辑放在控制器中。当您的控制器不仅仅是促进与视图之间的数据传输时，您应该考虑创建一个服务层。有时候，保持简单才是最好的解决方案。因为一个1000美元的问题而创造一个百万美元的服务层解决方案是不明智的。 - Michael Humelsine

@Matty-M 谢谢！如果我有一个服务层，那么服务层应该有一个带有 UnitOfWork 的插入/更新/删除方法吗？还是在其中调用工作单元的模型？ - Leandro De Mello Fagundes

@LeandroDeMelloFagundes 这就是我在服务层中所做的。仓储本身将处理crud操作，但我在服务层中有同名方法来处理任何业务逻辑，并在必要时创建工作单元并将其传递给仓储（在无法注入UOW的情况下）。 - Matt M

@MattyM，你的模型没有任何方法吗？只有代表表列的属性？插入/更新/删除不在你的模型中，对不对？抱歉问这么多问题，但我真的想了解更好的开始方式 :) - Leandro De Mello Fagundes

Answer 2

第三个问题...以及其他一些问题。

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

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

但是，根据应用程序的复杂性和大小，有许多方法可以解决这个问题。

- dav_i

Answer 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)

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

- danludwig