Model view controller 为什么模型视图控制器不是视图逻辑数据库？

我使用MVC模式已经5个月了。我同意MVC，这是组织思维的好方法。但每次我试着写模型时，我都会写模块，这一困惑引发了一个问题，为什么它是模型，而不是数据、数据库或存储等等。最不相关和通用的名称是模型

我同意这个观点，但我认为控制器应该是逻辑或路由器

来自维基百科：

该模式隔离了“域逻辑” （用户的应用程序逻辑） 从用户界面（输入和 演示文稿）

该模型管理应用程序域的行为和数据

控制器接收输入并通过调用模型对象启动响应

为什么我们使用模型、视图和控制器作为此模式的名称？

您引用的文本（重点稍微转移）指出，“模型管理应用程序域的行为和数据。”行为可以在数据库中定义为存储过程，但更常见的情况是，完全或至少部分地用应用程序的宿主语言（C/C++/C#/ASP/Perl/PHP/随便什么）对其进行编码

---

“模型”和“数据库”是不可互换的术语-模型不仅仅是数据库，它不仅仅是存储数据。

在设计良好的应用程序中，数据被称为“数据模型”。原因是我们以所谓的模型来构造数据，因为它是对业务概念的“建模”（例如，和订单可能有订单详细信息行，或者某个人可能是客户或员工）

这就是它之所以被称为模型的原因，因为它通常是真实数据结构的抽象，并且它通常不知道它是如何存储的（数据库、平面文件、内存、穿孔磁带、信鸽……等等）

---

这是一个通用的概念，因为模型不应该具体描述它的实现细节。

我同意Dave的观点：但也许我可以添加一点

你应该记住，层不应该知道比它低一层更多的东西

在我的例子中，控制器向一个模型发出请求：这恰好需要一个连接两个独立数据库的数据库视图……但控制器永远不应该知道这一点，这是一个很好的实践（MVC中唯一真正的实践？），它需要知道的是，当它请求一个模型时，模型知道如何获得它

这就是重点。模型对一个“东西”进行建模，控制器应该注意不知道它是如何得到“东西”的

具有讽刺意味的是，我发现在中添加一个可选但推荐的额外层：数据库抽象时，这变得更容易理解

这为分离添加了另一层。在安装程序（如Moodle）时，您会看到这一点，程序会询问您使用的数据库连接类型。它知道如何与数据库通信，但它所使用的语言在模型中是隐藏的

在正常使用中：控制器要求一个模型，模型要求数据库抽象层提供结果。 当您从MySQL更改为MSSQL/XML/carrier Pige时，该模型不需要任何更改

---

这就解释了为什么该模型不是“数据库模型”。它实际上与数据库无关。

这是一个相当杂乱的简明流程，我没有回答实际问题。你能澄清你的问题吗？