MVC is an architectural pattern, not a design pattern

When I first learned how to program, I read some books, an impressive book, "Design Pattern analysis," which gave me a lot of help with my later work.

He asked me to stand in the position of the problem model to specify the solution, but also taught me that every problem in software design can be refined to non-divisible atomicity.

After that book saw a number of design patterns of the book appeared. Because I am more advocating in the authority or the Orthodox academic books, not how to read other books.

It's wrong to say that MVC is a design pattern in some blogs that have been seen online in recent years, and MVC is actually a software architecture model.

I can say without a mention that some people say that MVC is a design pattern, basically a impostors programmer .

Because MVC does not have a prototype of the problem scenario in the design pattern, he is a generalization of a software architecture model, such as a factory model, where he can address the need to update frequently

Maintenance method code, as long as the parameter is passed in, he will give you objects, such as Java in the use of Class.forName to load classes.

I do not read much, the superficial understanding of MVC is as follows, for your reference:

MVC is a software architecture model, he simulates human social division of Labor, through the Division of labor to accomplish one thing, the completion of this matter may require many kinds of jobs, here we can put

These tasks are understood as roles and are understood as layers in the software.

For example, a project, the boss of the company to arrange for the designer to do the tender, bid to finish bidding, and then transfer the project to the Technical department project manager, the project manager to arrange technical personnel to install,

After the technician installs the feedback to the project manager, the project manager reports to the boss that the mark has been completed and this is the end of a project.

In this process: arranging, turning, reporting several words probably reflect the characteristics of the interactions among the various roles in a complete project, namely task scheduling and distribution, and

Task result feedback.

If the MVC architecture pattern is used in a project, regardless of the project size, the group/Role/Responsibility Division is probably the model layer, controller layer, view layer.

Model can be understood as the grass-roots, do some menial, basic work.

Controller can be understood as management, they are usually responsible for issuing commands, scheduling tasks

The view layer can be understood as the user interface and user interaction layer.

We have just examples of projects in: Boss, project manager they are controller layer, one is issued orders, a dispatch task

One of the design roles and the technical staff they are the model layer, they do the basic work, they have some rough interface on this layer, can and other characters of the people

To Exchange feedback task results.

Blog temporary A little idea, is spit groove, about the view layer I did not think of the detailed description of the way.

In the software MVC architecture, our Model,view,controller layer can be clearly divided, many online tutorials.

The author's understanding is that, regardless of whether there is an MVC framework in the project, a reasonable MVC framework design should follow these guidelines:

M-Layer data persistence layer, responsible for communicating with the database, which contains the data model entity classes, as well as some crud methods.

C layer is mainly responsible for scheduling tasks, the V-level requirements issued by the command, the most likely to be the task is forwarded to other classes of processing.

For example

DATASTOREBLL DBLL = new DATASTOREBLL ();

Dbll.dosave (Entity entity) {

Datastoredal Dbal = new Datastoredal ();

Dbal.dosave (entity);

}

The actual data Persistence task is forwarded to the DAL via the BLL, and the BLL only gets the processing results.

The C layer should not have database operation code, such as JDBC getconnection

The view layer is responsible for interacting with the user, showing the results to the user, which can be a Web Ui,cui,gui,app UI, etc.

Communication between tiers should depend on abstractions (interfaces or abstract classes).

MVC is an architectural pattern, not a design pattern