过去几天我一直在使用asp.net核心web api，我熟悉MVC和SOC等，但我对核心mvc教程感到困惑。 因此，在所有教程中（为了保持简单），他们将业务逻辑放在Controller中，但这不符合MVC。
一般来说，我创造了：
现在我对服务有点困惑，我还应该把业务逻辑放在哪里？我的意思是模型是一个地方，但我不希望我的控制器直接访问模型，但更像是Facade / Factory。 我们如何在aspnet中实现这一目标？
您可以在https://github.com/drakoumel/DatacircleAPI
找到我的工作回购我希望在我能够得到一个很好的解释之后，将它写在stackoverflow的文档中以帮助其他人。
答案 0 :(得分：5)
对此有很多方法，对你的问题没有一个正确答案。
基本上，您在视图中使用的模型不应该是您在数据库中持久存储的模型。因此，您可以做的是创建一个“服务”层，因此控制器在服务上运行，服务在存储库上运行。通过这种方式，您可以清楚地分离每个“层”之间的关注点。
首先，将持久性模型和业务逻辑保留在控制器之外。属于控制器的唯一逻辑是应用程序逻辑。
其次，介绍业务逻辑所属的业务逻辑层（AKA。服务层）。您还可以在该层中创建单独的模型，因此您的控制器不会在代表您的数据库实体的模型上运行，您只需在服务公开给您的控制器的模型和它们传递给存储库的模型之间应用映射。将这些服务作为依赖项提供给控制器。您的服务也会将您的存储库作为其依赖项。
这样你的控制器就不知道你的业务逻辑是什么 - 它只知道它必须调用一些服务来处理所有事情。您的服务不知道它在哪里使用，他对控制器，视图或数据在数据库中的存储方式一无所知 - 它只是执行您的业务逻辑。而您的存储库只是将您的实体存储在您选择的存储中，它们只知道它们的实体模型以及如何保留它。他们不知道有服务，控制者或观点。您获得的好处是，当您决定更改代码时，无论是最小允许客户年龄或机制或保存实体的业务验证逻辑，您可能只在代码中的一个位置执行此操作，负责该特定事情的地方。
请记住，这是您可以执行的这些组件之间最小的关注点分离。请注意，一切都取决于您的情况，并且在presentatio，业务逻辑和数据持久层之间创建简单的层并不总是正确或微不足道的事情，因为有时可能很难将您的业务逻辑泄漏到除了它们之外的层中实际上属于。