MVC：为什么分离模型，视图和控制器？

Question

除了它的“哲学”方面，让我的控制器也成为我的模特是一个坏主意吗？

似乎节省了一些编程时间。我不必在控制器和模型之间创建逻辑，因为它是一样的。我可以直接与视图互动。

将M和C分开是什么意思？模块化 - 即将一个模型和控制器集换成另一个模型的能力 - 将它们分开的唯一原因是什么？在我看来，“交换”模块的发生比（例如）必须更新模型和控制器要少得多，因为模型中的某些东西正在发生变化。

---

根据MVC概念，一个简单的计算器应该同时具有控制器和设置视图（如默认设置或其他东西），这似乎很奇怪。我知道这是一个简单的例子，但似乎适用于所有情况（除了框架）。

Answer 1

主要原因是代码的可重用性。如果你在职业生涯中只打算写一个程序，那么也许并不重要。如果你打算从事它的职业生涯，拥有可重复使用的部分是有价值的。精心设计的模型，控制器和视图类很容易进入其他程序。我一直这样做。

考虑UITableViewController，它是一个控制器。现在假设它是专门设计用于处理音乐曲目（模型），当你想要处理其他东西时，你需要创建一个完全不同的表管理类。避免这种噩梦是MVC在Cocoa中大量使用的原因。

还有其他方法可以解决问题。有些语言是子类而不是委托。但是在Cocoa中，分割程序的主要方法是MVC，它运行得很好。

编辑：来自开发商业应用程序世界的其他原因。

• MVC中的内存处理更容易。您可以保留模型对象，并在屏幕外显示对象（以及许多控制器对象）。

• 序列化未包含控制器和视图的模型对象更容易，并且以多种方式显示相同数据要容易得多。即使在“简单”文本编辑器中，您也可能希望能够进行分屏，或者有多个窗口显示同一文档。在MVC中，这很容易。

如果您现在或将来不需要灵活性，那么您不需要太多架构。但大多数真正的项目并非如此简单。 MVC源自Xerox编写大型程序的经验以及将所有内容组合在一起时遇到的困难。

---

编辑2：我正在看你之前的编辑：“根据MVC概念，一个简单的计算器应该同时拥有一个控制器和一个视图用于其设置（如默认值）设置或其他东西）。“

这正是MVC的原因。重新编码为计算器应用程序专门保存用户设置所需的所有内容似乎很疯狂。您需要一个通用的“请保存这些用户设置”，它与UI完全分开并且您可以重复使用。在OS X上，它被称为NSUserDefaults，Calculator应用程序以这种方式存储其配置。

Answer 2

MVC是一种标准模式，在开发社区中得到了很好的理解，并且有充分的理由。这种分离确实使事情易于阅读，易于排除故障，易于查找和易于测试，作为单独的组件，每个组件都有自己的职责范围。

你必须使用它吗？当然不是。但保持零件分离通常被认为是一个好主意。

Answer 3

控制器知道如何将特定视图链接到模型。除了改进文档和可维护性之外，模型和控制器的分离具有直接的好处，即允许多个视图从模型中显示相同的信息，而不会增加任何复杂性。

这不仅适用于同一应用程序中的多个视图，也适用于您应用程序的多个版本中的多个视图变体。您的模型是绝缘的，逻辑上是干净的。

在我看来，结合模型和控制器是一种经典的虚假经济。它可能会节省几分钟，但随着应用程序的发展和增长，它会花费很多。

Answer 4

如果它适合你，那么它的工作原理。期。模型，视图和控制器分离的原因围绕着企业应用程序的大多数开发都是由开发人员团队完成的想法。

想象一下，10位开发人员正在尝试使用您的控制器。但他们想要做的就是为模型添加一些东西。现在你的控制器坏了？他们做了什么？

Answer 5

模型通常是可以在控制器之间重复使用的独立组件。如果你绝对确定你不会在多个Controller中重复使用模型，我真的没有看到混合这些问题的问题。

我想有人可能会争论为什么即使你正在计划偏离，也要使用MVC设计。也许有适合您情况的更合适的模式。你能给我们举一个你在控制器是模型的地方做过的例子吗？这将有助于我们了解您正在努力做得更好。

Answer 6

MVC完全是关于管理（数据，表示和业务逻辑的分离）。所以就是这样：如果你经营一家小公司，拥有一个MS大小的管理层将是一个真正的拖累。但如果你是一家大公司，就不可能没有大型的中层管理人员。

老实说，在我的大部分课程作业中，我将模型和控制器结合起来，因为我没有看到分离的必要性。但是在大项目上工作？如果你试图不分开，那么缺陷就会非常明显。做你觉得正确的事。

Answer 7

模型既不依赖于视图也不依赖于控制器。这是分离的关键好处之一。这种分离允许独立于视觉呈现来构建和测试模型。