MVC 的优点是什么 [关闭]

MVC 清楚地分离了应用程序逻辑，这反过来大大简化了大型项目的工作。

Plus将是相同的：
1）方便地为不同类型的设备显示不同的视图（view），同时使用相同的数据；
2) 促进了代码的支持和测试。

顺便说一句，在这里，与所有模式一样，只有一个选项既方便又美观。按照MVC来划分角色既美观又方便，因为它在具有丰富图形界面的大型项目中具有战略优势。比方说，它对应于开发人员如何看待系统。允许您很好地本地化对这些单独实体的更改，以便它们不太可能同时更改。让我们快速了解一下变化的主要原因：

1. 更改数据结构——模型更改最多，控制器较小，视图可能根本不必更改。
2. 改变界面的逻辑——视图变化更多，然后是控制器，模型更少。
3. 纠正错误——首先，它们更容易发现，其次，简化了测试。
4. 大的结构变化——计划它们变得更容易，把它们分解成阶段。

项目变得更易于管理和可预测，这是设计的主要目标之一。

mvc- 为一件事而创建，将应用程序逻辑放在不同的层上，最好称为资产。

但首先，值得追根溯源，了解ареал这个问题парадигма，或者正如他们常说的那样мультипаттерн，是在什么情况下得到培育的。

这个概念是由Trygve Reenskaug在1979 年描述的语言Smalltalk......

我会题外话，让我自己假设开发人员php在读完html > css > js上一句后，只会注意旧语言的奇怪名称Smalltalk并继续阅读这个概念，甚至没有意识到他将无法完全明白了！

Smalltalk这是服务端和客户端都写的语言，它没有客户端（如html, css, js）和服务端（php, python, ruby）之分。您必须想象，为了创建一个按钮，您只需要创建它的对象。什么是按钮？这既是换皮又是事件的画面和逻辑。而这一切都已经封装在了按钮对象中。就像今天html，css放在js一起。

而当他们说他们mvc共享逻辑时，他们并不是说将按钮分开，而是指组件的分离以及管理这些组件的逻辑。也就是说，mvc在其原始来源中，这是应用程序的规则，而不是组件的规则。

但是时间向我们展示了程序员如何在不理解编写者的话的情况下Smalltalk学会了将所有内容分解为组件，包括组件。这是好是坏很难说。今天，谈到客户端-服务器应用程序，我们假设mvc要么mvvm在客户端mvp上，要么在服务器上，但在原始来源中没有客户端的概念，只有一个表示。假设浏览器是视图，服务器是模型。很难说，今天你唯一能猜到的就是那些年和今天的应用是不同的。那么，60 年代有哪些应用程序？数学上的，可能又是数学上的，浏览器可能甚至不存在。

所以，回到mvc.. 它的主要好处在于经济战略。也就是说，在创建将要开发的应用程序时以及将来将在其中创建应用程序的部分。毕竟，今天的应用程序大多是为特定任务而编写的。以常规站点为例，它被编写并被遗忘，它不可能被重构。或者，例如，在一场大型比赛中，人工智能将在各个比赛中使用。

或者记住应用程序逻辑必须在模型中的规则。但是仍然没有一个游戏或任何应用程序是模型的元音规则。在这种情况下，模型总是相同的，只是表示发生了变化。按照最佳传统，这是一个无需其他元素即可完全发挥作用的模型。所以我可以为 2D 和 3D 编写海战并节省程序员。

一切，这种范式没有其他优点，甚至没有被放下。

最后值得一提的是，mvcnot the last spur 并不是一个单一的整体架构解决方案。正如我之前所说，这个范例是一个连接部分，连接什么是完全无关紧要的。它不是房子，它是一个应用程序框架。至于墙壁和天花板，您可以使用任何东西，也可以使用较小的mvc。