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

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

看来节省了一些编程时间。我不必在控制器和模型之间创建逻辑，因为它们是同一件事。我可以直接与视图交互。

把M和C分开有什么意义？模块化——即能够将一个模型和控制器组替换为另一个模型和控制器组的能力——是分开它们的唯一原因吗？在我看来，“交换”模块的情况比（例如）必须更新模型和控制器要少得多，因为模型中的某些内容正在发生变化。

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

主要原因是代码的可重用性。如果您在职业生涯中只打算编写一个程序，那么也许这并不重要。如果您打算以此为职业，那么拥有可重复使用的部件就很有价值。设计良好的模型、控制器和视图类很容易放入其他程序中。我一直这样做。

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

还有其他方法可以分割事物。有些语言大量子类化而不是委托化。但在Cocoa中，分割程序的主要手段是MVC，而且效果很好。

EDIT:只是来自开发商业应用程序世界的更多原因。

• MVC 中的内存处理要容易得多。当视图对象（以及许多控制器对象）离开屏幕时，您可以保留模型对象并丢弃它们。

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

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

EDIT 2:我正在查看您之前的编辑：“根据 MVC 概念，一个简单的计算器应该同时具有控制器和设置视图（例如默认设置等），这似乎很奇怪。”

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