OOD（面向对象设计）和MVC（模型 - 视图 - 控制器）架构已成为现代软件设计的主要内容。然而，我最近就MVC架构如何利用（甚至可能违反）OOD原则进行了一次有趣的讨论。这种可能性实际上相当有趣，因为OOD和MVC都旨在实现许多相同的目标：关注点分离和软件可重用性。但我提出的问题是：这两种设计策略是否直接冲突？正如我在实践中使用过的那样，我开始思考：很可能是的。
我之所以这样说是因为：在模型，视图和控制器之间实施严格的分离通常会导致架构模型被实现为dumb 容器，只能通过外部控制器进行操作。我认为这直接冲突了面向对象设计的主要原则之一：对象包含执行必要操作的操作，并在必要时封装它们。例如，在纯面向对象的体系结构中，假设的File类将包含open()和save()等方法。 MVC建议我们有两个类File和FileManager（后者包含open()和save()方法。对我来说：MVC设计相当混乱。如果需要创建更专业的File类型（比如处理在open()或save()上通过网络流式传输的文件），则只需要子类File用一个名为（让我们说）的类：StreamedFile。使用MVC，您必须创建另一个管理器类或使原始管理器类的设计复杂化。
由此可见，在更复杂的系统中，MVC可能会对关注点分离和代码重用性产生灾难性影响。或不？也许MVC模式可以在不破坏OOD原则的情况下实现？或者，MVC本质上是一种有缺陷的方法，难以实现松散耦合组件的软件系统吗？
答案 0 :(得分：14)
相反，健康的MVC使用应该鼓励瘦的控制器和胖模型，以便模型（对象）是动作发生的地方（它本身鼓励封装）和其他良好的OOP原则），控制器只是指向对象的正确方向的某些请求。
答案 1 :(得分：5)
MVC中没有任何内容表明Model应该是愚蠢的（贫血模型）。我认为拥有丰富的Model课程是完全合适的，这样就不需要“经理人”了。
话虽如此，目前流行的做法是使用ViewModel将数据传递给View。 ViewModel基本上是针对特定Model量身定制的View投影。从Model的角度来看，它可以被视为View，是富人Model的外观;因此，Model还有更多内容，而不仅仅是ViewModel。
答案 2 :(得分：1)
我不会将MVC称为与OOD同样痛苦的架构。 MVC只是一种可以应用于某些设计的OOD模式。因此，它很简单，不会与OOD竞争，它只是构建好或坏OOD设计的工具之一。就像锤子不会与良好的木制工艺竞争一样，锤子就像MVC一样，只是工匠工具箱中的工具。
它既不是促进不良设计的模式。因为良好的OOD设计可以很好地分离关注点，所以MVC模式可以通过将表示关注点（视图）与应用程序逻辑（控制器）和更基本的域逻辑（模型）分开来为您提供。因此，它是一种经常应用于用户界面的良好OO模式。但是在制作好的OOD时还可以考虑其他竞争模式。
答案 3 :(得分：1)
我们有两种形式的MVC，Pull MVC和Push MVC（又名基于组件的MVC和Legacy MVC）。
推送MVC专注于概念的分离，每个模型 - 视图 - 控制器集处理应用程序的某些方面，并且可以由一些单独的人员设计和开发。当系统快速开发时，它运行良好，并且添加功能也很容易。大型系统中的代码重用变得非常糟糕。基本上只有模型被重复使用。
Pull MVC，通过使用小部件（视图组件）专注于代码重用，以便许多视图共享相同的代码并仅自定义其小部件。对于控制器，通用控制器实践被抽象和执行。
根据软件的性质和速度，将Pull和Push MVC混合起来。