我一直认为业务逻辑必须在控制器中，并且控制器（因为它是“中间”部分）保持静态，并且模型/视图必须通过接口进行封装。这样，您可以在不影响任何其他因素的情况下更改业务逻辑，对多个模型（每个数据库/存储类型一个）进行编程，并为多个视图（例如针对不同的平台）编程。
现在，我在这个问题中读到，您应该始终将业务逻辑放入模型中，并且控制器与视图紧密相连。
对我来说，这没有任何意义，它意味着每次我想拥有一种支持另一种数据库/存储类型的方法时，都必须重写包括业务逻辑在内的整个模型。
如果我想要另一个视图，则必须重写视图和控制器。
有人可以解释为什么会这样，还是我在某个地方出错了？
Answers:
ElYusubov的答案主要是定论，领域逻辑应该进入模型，而应用程序逻辑应该进入控制器。
有两个澄清：
您和编程界的大部分人似乎误解了MVC部分的作用。简而言之，它们是：
模型 =领域逻辑
视图 =输出逻辑
控制器 =输入逻辑
这意味着该模型负责整个业务逻辑：与在屏幕上绘制小部件，驱动打印机，将数据输出为HTML，解析HTTP请求等有关的任何事情都不属于模型。
但是，许多现代的所谓的“ MVC”框架实际上根本不执行MVC，否则会误标记其部件。通常，所谓的“模型”是模型的持久层，而业务逻辑位于他们所谓的“控制器”中。实际的控制器通常只是一个带有路由表的中央入口点，并在各个“控制器”中添加一些代码，以将收到的输入分配给正确的业务流程。这些框架所谓的“视图”实际上包含了所有内容：一些表示逻辑（视图），一些输入处理和验证（控制器）以及一些其他业务逻辑（模型）。通常，实际视图的大部分被称为“模板”。
您可能还想阅读有关多层体系结构的信息。MVC是一种单向的（流程是Controller-> Model-> View），Multi-Tier是一种双向的东西（Presentation-> Logic-> Data-> Logic-> Presentation），还有很多假装做MVC的框架实际上是三层的，重新标记了“从视图到视图”，“从逻辑到控制器，从数据到模型”的标签。
为了真正隔离业务逻辑并使之与表示层基础结构分离，应将其由应用程序服务封装。MVC体系结构是实现表示层的一种方法，它应该保留在该范围内，将所有业务逻辑委托给这些应用程序服务。将视图模型视为视图和需要在其上显示或读取的数据之间的适配器。控制器调解承载业务逻辑的视图模型，视图和应用程序服务之间的交互。
应用服务实现业务用例，并与表示层分离，无论是MVC还是其他。反过来，应用程序服务可以托管事务脚本或域驱动的设计。
对于存储，应用程序服务可以引用存储库或持久性机制的任何抽象。通过将数据访问抽象到一个接口中，可以支持不同的实现。通常，这些抽象是泄漏的，并且只能在实现中部分移植，这通常是徒劳的尝试，无法实现完全的可移植性。
更新
我的建议是基于六角形建筑。在六边形体系结构中，您的域模型（业务逻辑）是核心。此核心由充当外观的应用程序服务封装。应用程序服务是简单的类，具有与您域中的用例相对应的方法。有关应用程序服务的深入讨论，请查看域驱动设计中的服务。该代码示例包含a PurchaseOrderService，它是用于购买域的应用程序服务。（请注意，应用程序服务并不意味着使用域驱动的设计。）
在六边形体系结构中，MVC表示层是域模型（业务逻辑）和GUI之间的适配器。域模型不知道表示层，但是表示层知道域模型。
与将业务逻辑放置在控制器中的解决方案相比，该解决方案当然具有可移动的部分，您应该权衡弊端和好处。我之所以建议这样做，是因为我更喜欢使业务逻辑与表示层分离，以应对复杂性。随着应用程序的增长，这一点变得更加重要。
取决于您所指的业务逻辑。任何赋予模型内容含义的“逻辑”都应该在模型中。在链接的问题中，投票率最高的答案似乎将“业务逻辑”定义为与数据相关的任何事物；从企业的数据就是其业务的角度来看，这是有道理的！
我曾经看过Rails的创建者（我认为）的一个例子，他正在对此进行精确的介绍-不在模型中添加“业务逻辑”。他的示例是用于应用程序注册和登录的控制器类和方法-以明文形式提供的密码在插入模型或对模型（数据库）进行查询之前已经过加密。
我想不到一个更好的例子，它不是控制器逻辑，而是直接属于模型。
该模型可以作为无数数据存储的接口，从而减轻了可移植性问题。在这里，无论模型接口是否实际上是“控制器”，人们都可能会感到困惑。
一般来说，控制器链接模型和视图（这是应用程序的基本要素）。在Cocoa开发中，可以简化到通过XCode GUI（控制器对象和绑定）处理控制器的程度。
关于MVC的GoF的“设计模式”部分，引用松散：
MVC三元组类用于在Smalltalk-80中构建用户界面。模型是应用程序对象，视图是其屏幕显示，控制器定义了UI对用户输入的反应方式。MVC通过在视图和模型之间建立订阅/通知协议来分离它们。下图显示了一个模型和三个视图。为了简单起见，我们省略了控制器。
MVC都是关于UI的。重点在于模型和视图-定义和显示数据。请注意“订阅/通知协议”-这是您的控制器所在的位置。您可以构建所需的所有视图。只要他们遵守协议，您就无需接触模型或控制器。
如果您是专门谈论Web开发，恕我直言，许多流行的Web框架都带有术语MVC及其组件定义，因此既快速又宽松。