Answers:
但这并不总是可能的。我不能给您20％或10行这样的硬数字，这取决于无法回答的问题。我可以描述一下我如何使用需要稍微弯曲的设计模式和环境。
在我看来，这完全取决于应用程序的目的。构建一个简单的REST API来发布？忘记干净的分离甚至图案。您可以在不到一个小时的时间内推出工作版本。建立更大的东西？大概最好去做。
目标是构建单独包含的系统。如果您开始编写特定于两个系统如何交互的业务逻辑，那将是一个问题。如果不深入研究，我无法给出意见。
设计模式是模子，有些人喜欢在主要和写得很好的代码的基础上严格遵守它们。严格遵守模式可能不会给您不好的代码，但是可能会花费更多时间并导致您编写更多代码。
设计模式是灵活的，调整它们以满足您的需求。过度弯曲它们，尽管它们破裂。知道您需要什么，然后选择最接近的设计模式。
术语“业务逻辑”经常引起混淆，因为人们对此有不同的看法。我认为，术语“业务逻辑”涵盖两个领域
域逻辑是与业务相关的核心领域相关的逻辑，因此，如果为会计师编写应用程序，则税法，簿记规则等都是域逻辑的一部分。
应用程序逻辑是与您正在运行计算机程序的事实有关的逻辑。这可以是诸如CSV导入导出，向导等之类的内容。还可以包含诸如创建忘记密码的电子邮件之类的内容。
您可以在控制器层中放置的“业务逻辑”是应用程序逻辑。也许不是所有的应用程序逻辑都应该放在那儿。但是永远不要将域逻辑放在控制器层中。那显然应该在域层中。
您在谈论格式化或清理数据的逻辑。格式一定是应用程序逻辑。另一方面，如果清理数据基于域规则，则清理可能是领域逻辑。这取决于上下文。
控制器应该对域逻辑非常了解。
控制器应委派任务，例如通过抽象服务/存储层从数据存储中检索记录，以及通过相同（或相关）服务将数据传递回数据存储中。至于这些操作之间的机制和更精细的工作，通常它们属于控制器以外的其他位置。
我经常发现自己在控制器中添加了小型数据清理方法，这些方法将数据保存回存储中，尽管这是一种有效的解决方案，但它与控制器的预期作用并不匹配。理想情况下，任何将要修改，验证或解析模型的事物都应在模型本身附近（如果不在模型内部）发生。例如，如果您需要在存储之前“清理”模型对象，请考虑在模型上或作为处理存储模型的服务的一部分使用SanitizeInputs（）方法。
从务实的角度来看，我发现，当您尝试做某种没有良好的模式兼容方法的事情时，您要么在控制器中遇到逻辑，要么在模型中出现控制器行为。令人怀疑的是，如果您要编写的应用程序背后没有大型基础架构。
您可以选择任一种方式，但我通常会尝试考虑是否在多个控制器动作中出现怪异的现象，如果出现在模型中。如果不清楚，我尝试考虑它是否更适合某个地方而不是另一个地方。我通常将其放在模型中只是为了使其不受控制器影响（个人偏爱较小的控制器和更强大的数据对象，YMMV）而失败
第三种选择是将实用程序项引用为单独的实用程序类，但是在许多人看来，这也与模式不符。
另外，仅仅因为您没有严格遵循模式，您不一定就在灾难中调情。除非您真的希望这个项目重用大量代码，否则我会更加担心该项目与自身的一致性（即：一旦选择一个位置，不要在放置这些位的位置上翻转）而不是出于某种原因想要节省项目中间部分的重写。记录/注释您偏离普通模式的位置以及原因，并为此应用程序定义期望的模式。
MVC在某一点上偏离既定模式本身。
像编程中许多其他有趣的概念一样，MVC是一种强大的范例，可以将结构和焦点集中在一系列紧密或相似的策略上，以实现特定的场景。
像许多其他编程概念一样，MVC简化了现实，丢弃了很小的细节，并提供了可遵循的粗略线框模型。像对现实的许多其他简化一样，它确实可以使人为的结构陷入混乱。
但是，像许多其他编程概念一样，MVS只是现实的简化。这不是完美的，也不是彻底的。这就是为什么不可能将现实世界中的情况放入过于简化的模型中的原因。因此出现了许多与此类似的问题。
控制器应加入多少逻辑？
视图是否应包含任何条件逻辑？
模型是否应包含未在业务实体中直接找到的其他数据？
这些都是为了调整代码以准确，完全地适应MVC概念而产生的问题。
我对你的回答是不要尝试。MVC提供了结构。在此基础上构建应用程序，但不要期望它完全适合。会有偏差，这是正常现象。只要注意保持他们的控制。