我知道这是一个巨大的文本，但在此先感谢您阅读。真的很欣赏。
让我们想象一下我正在使用MVC。控制器收到了用户的请求。在控制器中执行逻辑并返回响应。
人们说控制器不执行任何逻辑，它们只是将传入的请求提供给服务，而所有逻辑都保留在服务类方法中。但是我不明白为什么这很好。
参数1），这是很好的，因为您有瘦的控制器而不是胖的控制器。但是谁在乎瘦控制器，如果它不能给您带来好处呢？
参数2）：您的业务逻辑位于其他位置，并且未与控制器耦合。为什么这个论点甚至值得一提？好的，我在服务类的方法中拥有所有逻辑，在我的控制器中，有两行代码。那给我什么？服务类别仍然很大。这是某种好处吗？
参数3）甚至有人告诉我，服务层是好的，因为从服务方法中，您将对象返回给控制器，而在控制器中，有时我们返回json或其他格式。他告诉我，如果我们同时拥有桌面/网络/移动应用程序，并且正在为他们编写api，那么这很好。但还是没有道理。
人们最讨厌的是他们使用存储库和服务（在服务方法中，他们具有业务逻辑和存储库类的方法调用）。
这是我的想法。如果使用服务类（我称其为助手），则在服务方法中，应该没有与框架相关的东西。如果有依赖于框架的代码，那就不好了，因为我所有的业务逻辑都与框架紧密耦合。我的朋友建议我将get，insert，update雄辩的调用放入控制器，并将结果传递给进行数据修改的helper（service）。这种测试助手（服务）的方式根本不需要注入存储库或模型。以及为什么我们甚至需要测试存储库或模型（框架已经对其进行了测试）。
我需要您的帮助，这是我第一次真正希望人们能够真正帮助我。我一直在考虑这个问题，但是我已经一个月都没有得到它。我什至对我的项目有最后期限，而且我不想写不好的代码。项目规模巨大。我只需要了解为什么服务层会为我提供帮助。事情是我读了太多（太多的东西你无法想象），而且没有一篇文章真正说出真正的好处。我们是否可以通过示例讨论优缺点？我也想和有经验的人私下聊天。我会做任何事情来理解这一点。
答案 0 :(得分：1)
抽象。
大多数人都赞成的理论是，所有功能都应该只做一件事情，一件事情做好。记住这一点，一种巨大的控制器方法没有任何意义。
但是在控制器文件中仅使用许多私有方法呢？
调试私有方法可能比公共方法更难，因为您通常无法访问它们以进行单元测试。为什么不只是公开它们，而仍将它们保存在同一文件中？因为那不是我们做事的方式。在MVC模型中，关注点分离非常重要。
以下是控制器在MVC中的工作方式：
控制者不应该在意业务逻辑-复杂的逻辑应该只是一个黑盒，对于控制者而言，可以正常工作。
此外，如果您有外部API调用，则控制器绝对不应直接执行它们。应该将它们隐藏在connectors包中，并通过服务层进行访问。
我认为使用服务层的主要目的是，如果您的业务逻辑发生了变化，那么您的控制器就不必在意。您的控制器应尽可能“愚蠢”。
为了使应用程序的每一层尽可能可靠和可预测，您需要确保每一层都有定义的用途-控制器不应接受输入，执行复杂的逻辑并提供输出。显然，如果逻辑很小，那么对其进行抽象化可能有点过大，但这是一个养成的好习惯。
最后，它使其他人更容易调试代码。如果您从该项目继续前进，而其他人必须从您上次停下来的地方继续工作，如果您的代码全部放在一个地方，那么他们会讨厌您。当所有东西都在一起时，查找错误并进行改进非常困难。如果您遵循约定并将业务逻辑与控制者分开，您将使其他人的生活变得更加轻松，因为他们知道会发生什么。
基本上，就做吧。这是一个很好的习惯，可以让您的生活变得更轻松。
答案 1 :(得分：0)
我将尝试给出简单的答案 尝试为胖控制器写最统一的代码...
最好测试类甚至接口方法，而不是返回视图的控制器方法。前提条件和责任较少的测试方法更好。控制器的方法是互连所有逻辑的最终方法。 Http处理，验证，业务等等。对于单元测试，调试和重用，最好将这些逻辑部分分开保存。