我还是很喜欢编程，但已经使用PHP \ CodeIgniter一两年了。
我最近通过将所有数据检索选项放在模型中来保持我的控制器非常干净，只需通过模型在控制器中加载和检索数据，然后将其传递给视图。
现在我也有脚本例如ping一些IP并报告状态，此时我在模型中有这个“动作”，将结果反馈回DB，然后另一个模型/方法拉动结果到需要该信息的应用程序的一部分。我认为这是最干净的方式。
昨天我遇到了一篇文章/讨论，其中人们指出一些代码是“错误的”，因为用户在模型中执行“操作”而不是仅仅检索数据，这显然是所有模型应该做的。
所以我的问题是，为了保持我的代码干净但坚持最佳实践，哪里是保持我的行为的最佳位置？有些动作可以容易50-100行，所以我不希望它们堵塞我的控制器。
我知道没有一个完美的答案，因为每个人做的事情都不同，我只是想知道你有多少年的经历以及你做了什么？
由于 [R
答案 0 :(得分：1)
我在做MVC时总是使用逻辑......
我想要FAT模型和SKINNY控制器......例如，大量逻辑进入模型以便于重复使用，控制器应该精简以便于阅读/跟踪。
只需2美分......（或2便士）
答案 1 :(得分：0)
模型的工作是表示问题域，维护状态，并提供访问和改变应用程序状态的方法。 Model层通常分为几个不同的层：
红旗：如果符合以下条件，我的模型架构可能会变坏：
如果上述“红旗”条件开始发生，那么我可能有一个打破封装的模型层。通过让服务层引用会话，我还创建了一个很难在没有整个应用程序的情况下进行测试的模型。此外，在模型中使用会话引用使得模型难以在不同的控制器中重用（根据我之前提到的web / API拆分）。
阅读此PDF
View的工作是将数据转换为可视化呈现，以响应客户端（即Web浏览器或其他消费者）。数据主要由财务主任提供;但是，View也可能有一个帮助程序，可以检索与呈现相关联的数据，而不一定是当前请求（例如，除了数据，页脚数据）。
红旗：如果符合以下条件，我的视图架构可能会变坏：
如果上述“红旗”条件开始发生，那么我可能有一个做太多的View层。应将业务逻辑分解为Service对象。并且，会话引用可能应该被分解为Helper对象或Controller。这将使视图更容易构建和测试，因为它们仅依赖于数据而不是整个应用程序。
注意：视图渲染是我仍然模糊的东西。我目前的方法使用仅CFM方法进行渲染;因此，将组件集成到视图渲染生命周期中仍然需要考虑。
Controller的工作是将传入的请求转换为传出的响应。为此，控制器必须获取请求数据并将其传递到服务层。然后，服务层将Controller注入的数据返回到View中进行渲染。此视图可能是标准Web请求的HTML;或者，它可能类似于RESTful API请求的JSON（JavaScript Object Notation）。
红旗：如果出现以下情况，我的控制器架构可能会变坏：
如果上述“红旗”条件开始发生，那么我可能有一个控制器层做得太多了。我应该将逻辑分解为一个可以由Controller调用的更具凝聚力的服务层。此外，如果Controller在不传递参数的情况下向Service层发出请求，那么我可能有一个打破封装的Service层（例如，引用Session，CGI，FORM或URL范围）。
答案 2 :(得分：0)
你的想法并非完全错误。
无论如何把控制器变小是一个非常棒的做法imho。这是反对建立“胖”控制器。 但我认为在您的情况下，您必须在单独的类（服务层）中解耦“业务逻辑”并在控制器中使用它。 仅仅是“关注点分离”。只需在控制器外部构建域逻辑“框架无关”。
除了将模型的数据转发给视图外，控制器还没有业务逻辑或其他一些东西的责任，相反，你违反了单一责任原则。
Paul M Jones在http://pmjones.io/adr/找到了ADR模式的良好起点，并向您展示了如何将业务领域逻辑与框架分离。
我还建议您进入DDD以了解更灵活的应用程序架构
答案 3 :(得分：0)