why model view controller is not view logic database?

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 fo开发者_运维技巧r 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?

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.

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.