我使用 MVC 模型已经 5 个月了。我同意 MVC，这是一种组织思想的好方法。但是每次我尝试编写模型时，我都会编写模块，这种混乱引发了一个问题，为什么它是模型，而不是数据或数据库或存储等。最不相关和通用的名称是模型。
我对视图没问题，但我认为控制器应该是逻辑或路由器。
来自维基百科：
该模式隔离了“域逻辑” （用户的应用程序逻辑） 从用户界面（输入和 演示文稿）
模型管理应用程序域的行为和数据
控制器接收输入并通过调用模型对象来发起响应
为什么我们使用模型、视图和控制器作为这种模式的名称？
【问题讨论】：
您引用的文字（重点稍有偏移）指出“模型管理应用程序域的行为和数据。”行为可以在数据库中定义为存储过程，但更常见的是完全或至少部分使用应用程序的宿主语言（C/C++/C#/ASP/Perl/PHP/whatever）进行编码。
“模型”和“数据库”是不可互换的术语 - 模型不仅仅是数据库，它的作用也远不止存储数据。
【讨论】：
在设计良好的应用程序中，数据被称为“数据模型”，原因是我们将数据构建在所谓的模型中，因为它是对业务概念的“建模”（例如，订单可能包含订单详细信息）行，或者一个人，可能是客户或员工）
这就是它被称为模型的原因，因为它通常是对真实数据结构的抽象，并且通常不知道它的存储方式（数据库、平面文件、内存中、穿孔磁带、信鸽......无论..)
这是一个通用概念，因为模型不应该具体说明它的实现细节。
【讨论】：
我同意戴夫的观点：但也许我可以补充一点……
你应该记住，这些层不应该知道比它低一层的任何东西......
在我的例子中，控制器向模型发出请求：这恰好需要一个数据库视图连接两个独立的数据库......但是控制器永远不应该知道这一点是一个很好的做法（MVC 中唯一真正的做法？） - 它只需要知道当它请求一个模型时，模型知道如何得到它。
这就是重点。模型为“事物”建模，控制器应该明确表示不知道它是如何获得“事物”的。
具有讽刺意味的是，当您添加一个可选但推荐的额外层时，我发现这变得更容易理解：数据库抽象。
这为分离增加了另一层。您在安装程序（例如 Moodle）时会看到这一点，它会询问您使用哪种类型的数据库连接。它知道如何与数据库对话，但它使用的具体语言对模型是隐藏的。
在正常使用中：控制器请求模型，模型向数据库抽象层请求结果。 当您从 MySQL 更改为 MSSQL / XML / 信鸽时，模型不需要更改。
这解释了为什么该模型不是“数据库模型”。它实际上与数据库无关。
【讨论】：