我是网络开发的新手，阅读了一些关于MVC的维基和讨论。但是，我读的越多，我对它的设计目的就越混乱。
我只是想知道为什么这个设计模式被发明了？它用来解决什么问题？
提前致谢。
答案 0 :(得分：4)
MVC范例的目标实质上是确保代码分离的形式。在开发代码时经常出现的问题是代码是连续编写的，其中每个部分都遵循另一个部分，每个部分直接依赖于其他部分正在做什么。
在处理大型项目时，维护和进一步开发代码很快就会成为一个问题。因此，您可以以简化的方式论证MVC范例试图做的是确保您将业务逻辑（例如执行的代码）与表示逻辑（显示结果的代码）分开。但这两个部分需要相互通信，这是控制器负责的。
这允许清晰的代码结构，其中不同的部分更加分离，意味着彼此更少依赖。
分离还意味着您以更加模块化的方式工作，其中每个部分通过接口（一些定义的函数和用于调用其他部分的变量）与其他部分交互，以便您可以更改基础功能无需更改代码的其他部分，只要您的界面保持不变。
所以它试图解决的问题是避免使代码库纠缠不清，以至于你不能在不破坏代码的情况下改变或添加任何东西，这意味着你必须在除了你之外的各种地方修改代码。做了你原来的改变。
答案 1 :(得分：1)
在某种程度上，它是寻找问题的解决方案。
作为一个相当古老的程序员，我很清楚“关注点分离”的好处，但是（在我不那么谦虚的意见中）MVC不能很好地做到这一点，特别是当实施“烹饪书”时“时尚。通常它只会导致模块的激增，每个功能都有三个独立的模块，没有通用代码或通用主题将事物联系在一起并实现真正的目标：最小化复杂性并最大化可靠性/可维护性
“经典”MVC在您的典型手机GUI应用程序中尤其不合适，例如，数据库表的管理可能与相应表格视图的管理密切相关。将逻辑分散在三个不同的模块中只会使事情变得更复杂，更难维护。
通常运行良好的是考虑您的数据并了解需要哪些类型的更新和查询，然后为数据库（或您使用的任何数据存储）构建“包装器”，以“抽象”它和最小化DB与系统其余部分之间的交互。但是计划这是 hard ，并且经常需要大量的反复试验 - 绝对不是烹饪书。
同样地，你有时可以抽象出其他领域，但是抽象，比如说，GUI界面通常太难以值得 - 不要只写“包装”来说你做了。
请记住，数据库，GUI系统，应用程序流控制机制等的作者已经付出了相当大的努力（有时候太多）来抽象这些接口，因此您的进一步“抽象”通常只是一个额外的调用层（特别是如果你采用烹饪书方法）。
答案 2 :(得分：0)
创建模型视图控制器是为了在代码中分离关注点，而不是在单个blob中创建一个hodge podge。 （意大利面条代码）视图代码只是表示逻辑，模型是表示域的对象，控制器处理业务逻辑和后端服务的集成。