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

Question

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

• 它应该在模型里面吗？模型应该有所有的业务 调用工作单元以插入或不插入数据之前的逻辑 数据库?

• 应该在控制器里吧？在调用模型之前？

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

这个问题没有 "correct" 答案，主要是基于意见。您可以在以下项目 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)

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