使用MVC + Repository Pattern，Business Logic应该在哪里？

Question

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

• 它应该在模型中吗？模型应该拥有所有业务 调用unitofwork之前的逻辑插入或不插入数据 数据库？

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

没有＆＃34;正确＆＃34;回答这个问题，它主要是基于意见的。您可以在以下项目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)

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