我正在使用MVC模型5个月 . 我同意MVC，组织思想的好技巧 . 但每当我尝试编写模型我编写模块时，这种混淆就会产生一个问题，为什么它是模型，而不是数据或数据库或存储等等 . 大多数不相关和通用的名称都是模型 .
我很有观点，但我认为控制器应该是逻辑或路由器 .
来自维基百科：
模式从用户界面隔离“域逻辑”（用户的应用程序逻辑）（输入和表示）模型管理应用程序域的行为和数据控制器接收输入并通过调用模型对象启动响应
为什么我们使用模型，视图和控制器作为此模式的名称？
我同意戴夫的观点：但也许我可以补充一下......
你应该记住，图层不应该知道它下面的任何一层......
在我的例子中，控制器向模型发出请求：这恰好需要一个数据库视图连接两个独立的数据库...但是，控制器永远不会知道这一点的好习惯（MVC中唯一真正的实践吗？） - 所有这一切需要知道的是，当它要求模型时，模型知道如何获得它 .
这才是重点 . 模型模拟“事物”，控制器应该不知道它是如何得到“事物” .
具有讽刺意味的是，当你添加一个可选但推荐的额外图层时，我发现这变得更容易理解：数据库抽象 .
这为分离增加了另一层 . 您在安装程序（例如Moodle）时会看到这一点，它会询问您使用的数据库连接类型 . 它知道如何与数据库通信，但确切地说它使用的语言是从模型中隐藏的 .
在正常使用中：控制器要求模型，模型向数据库抽象层询问结果 . 当您从MySQL更改为MSSQL / XML /载体鸽时，该模型不需要更改 .
这解释了为什么模型不是“数据库模型” . 它实际上与数据库无关 .
您引用的文本（强调移位了一点）表明“模型管理应用程序域的 behavior 和数据” . 行为可以在数据库中定义为存储过程，但它是主机语言（C / C / C＃/ ASP / Perl / PHP /等等） .
“模型”和“数据库”不是可互换的术语 - 模型不仅仅是数据库，它不仅仅是存储数据 .
在设计良好的应用程序中，数据被称为“数据模型” . 原因是我们将数据构建在所谓的模型中，因为它“建模”了业务概念（例如，订单可能包含订单明细行，或者一个人可能是客户或员工）
这就是为什么它被称为模型，因为它通常是真实数据结构的抽象，并且它通常不知道它是如何存储的（数据库，平面文件，内存，穿孔带，载体......等等......）
这是一个通用的概念，因为模型不应该具体说明它的实现细节 .
3 回答
我同意戴夫的观点：但也许我可以补充一下......
你应该记住，图层不应该知道它下面的任何一层......
在我的例子中，控制器向模型发出请求：这恰好需要一个数据库视图连接两个独立的数据库...但是，控制器永远不会知道这一点的好习惯（MVC中唯一真正的实践吗？） - 所有这一切需要知道的是，当它要求模型时，模型知道如何获得它 .
这才是重点 . 模型模拟“事物”，控制器应该不知道它是如何得到“事物” .
具有讽刺意味的是，当你添加一个可选但推荐的额外图层时，我发现这变得更容易理解：数据库抽象 .
这为分离增加了另一层 . 您在安装程序（例如Moodle）时会看到这一点，它会询问您使用的数据库连接类型 . 它知道如何与数据库通信，但确切地说它使用的语言是从模型中隐藏的 .
在正常使用中：控制器要求模型，模型向数据库抽象层询问结果 . 当您从MySQL更改为MSSQL / XML /载体鸽时，该模型不需要更改 .
这解释了为什么模型不是“数据库模型” . 它实际上与数据库无关 .
您引用的文本（强调移位了一点）表明“模型管理应用程序域的 behavior 和数据” . 行为可以在数据库中定义为存储过程，但它是主机语言（C / C / C＃/ ASP / Perl / PHP /等等） .
“模型”和“数据库”不是可互换的术语 - 模型不仅仅是数据库，它不仅仅是存储数据 .
在设计良好的应用程序中，数据被称为“数据模型” . 原因是我们将数据构建在所谓的模型中，因为它“建模”了业务概念（例如，订单可能包含订单明细行，或者一个人可能是客户或员工）
这就是为什么它被称为模型，因为它通常是真实数据结构的抽象，并且它通常不知道它是如何存储的（数据库，平面文件，内存，穿孔带，载体......等等......）
这是一个通用的概念，因为模型不应该具体说明它的实现细节 .