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