为什么模型视图控制器不是视图逻辑数据库？
我使用 MVC 模型已有 5 个月了。我同意 MVC，组织思维的好技术。但是每次我尝试编写模型时，我都会编写模块，这种混乱会产生一个问题，为什么它是模型，而不是数据或数据库或存储等。最不相关和通用的名称是模型。
我对视图没问题，但我认为控制器应该是逻辑或路由器。
来自维基百科：
该模式隔离“域逻辑” （用户的应用逻辑） 从用户界面（输入和 演示）
模型管理应用程序域的行为和数据
控制器接收输入并通过调用模型对象来启动响应
为什么我们使用模型、视图和控制器这个模式的名称？
I'm using MVC model for 5 months. I agree with MVC, good technique for organizing mind. But every time I try to write model I write module, that confusion rised a question, why it is model, not data or database or storage or etc. Most irrelevant and generic name is model.
I'm okey with view, but controller should be logic or router I think.
From wikipedia:
The pattern isolates "domain logic"
(the application logic for the user)
from the user interface (input and
presentation)The model manages the behavior and data of the application domain
The controller receives input and initiates a response by making calls on model objects
Why we use model, view and controller as name of this pattern?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您引用的文本（重点稍有转移）指出“模型管理应用程序域的行为和数据”。行为可以在数据库中定义为存储过程，但更常见的是完全或至少部分使用应用程序的主机语言（C/C++/C#/ASP/Perl/PHP/其他语言）进行编码。
“模型”和“数据库”不是可以互换的术语 - 模型不仅仅是数据库，它的作用也不仅仅是存储数据。
The text you quoted (with the emphasis shifted a bit) states that "The model manages the behavior and data of the application domain." Behavior can be defined within the database as stored procedures, but it's much more common for it to be coded either completely or at least partially in the application's host language (C/C++/C#/ASP/Perl/PHP/whatever).
"Model" and "database" are not interchangeable terms - the model is much more than just the database and it does much more than just storing the data.
我同意戴夫的观点：但也许我可以添加一点...
您应该记住，各层不应该知道比它低一级以上的任何内容...
在我的例子中，控制器向模型发出请求：这恰好需要一个数据库视图连接两个单独的数据库...但是控制器永远不应该知道这一点是很好的做法（MVC 中唯一真正的做法？） - 它需要知道的是当它请求模型时，模型知道如何获得它。
这就是重点。该模型对“事物”进行建模，并且控制器应该注意不知道它如何获取“事物”。
具有讽刺意味的是，我发现当您添加可选但推荐的额外层时，这会变得更容易理解：数据库抽象。
这为分离增加了另一层。您在安装程序（例如 Moodle）时会看到这一点，它会询问您使用什么类型的数据库连接。它知道如何与数据库对话，但它使用的具体语言对模型来说是隐藏的。
在正常使用中：控制器请求模型，模型向数据库抽象层请求结果。
当您从 MySQL 更改为 MSSQL / XML / 信鸽时，模型不需要任何更改。
这解释了为什么该模型不是“数据库模型”。它实际上与数据库无关。
I concur with Dave's point: but maybe I can add to it a bit...
You should remember that the layers should not know anything more that one level below it...
In my case, the controller does a request to a model: this happens to require a database view joining two separate databases... BUT it's good practice (the only real practice in MVC?) that the controller should never know this - all it needs to know is that when it asks for a model, the model knows how to get it.
That's the point. The model models a "thing", and the controller should make a point of not knowing HOW it gets the "thing".
Ironically, I find this becomes easier to understand when you add an optional but recommended extra layer in as well: Database abstraction.
This adds another layer to the separation. You see this when installing programs (Such as Moodle), which ask you what type of database connection you use. It knows how to talk to databases, but exactly what language it uses is hidden from the Model.
In normal usage: The controller asks for a model, the model asks the database abstraction layer for the results.
When you change from MySQL to MSSQL / XML / carrier pigeon, the model requires no changes.
THAT explains why the model isn't the "database model". It's actually not to do with a database.
在设计良好的应用程序中，数据称为“数据模型”。原因是我们在所谓的模型中构建数据，因为它对业务概念进行“建模”（例如，订单可能有订单详细信息行，或者一个人，可能是客户或员工）
这就是为什么它被称为模型，因为它通常是真实数据结构的抽象，并且通常不知道它的存储方式（数据库、平面文件、内存、穿孔磁带、信鸽...无论如何..）
这是一个通用概念，因为模型不应该具体说明其实现细节。
In a well designed application, the data is called a "data model" The reason is that we structure the data in what's called a model, because it's "modeling" the business concepts (for example, and order may have order detail lines, or a Person maybe a customer or an employee)
This is why it's called the Model, because it's typically an abstraction of the real data structure, and it is typically agnostic as to how it's stored (database, flat files, in memory, punched tape, carrier pigeon... whatever..)
It's a generic concept because the Model should not be specific about it's implementation detail.