An analysis of the difference between three-layer architecture and MVC pattern

MVC Pattern Description:

The full name of MVC is Model Viewcontroller, which is the abbreviation for Models-View-controller, a software design paradigm used to organize code in a way that separates business logic from data display. The premise of this approach is that if the business logic is aggregated into a component, and the interface and user interaction around the data can be improved and customized without rewriting the business logic MVC is uniquely developed to map the traditional input, processing, and output functions in a logical graphical user interface structure.

MVC is the architecture of the presentation layer, and MVC's model is actually the view model, which is the data for the view to show. The View model does not contain business logic and does not contain data reads.
In the N-tier architecture, there is usually a model layer that corresponds to the database table, which is called the O in Orm. This model may be poco, or it may be an entity class that contains some validation logic, and generally does not contain data reads. Data is read by the data access layer. MVC, as the UI layer, typically does not manipulate the data access layer directly, and there is a business logic layer that encapsulates the business logic and invokes the data access layer. The UI layer (Controller) obtains the data (model) through the business Logic Layer and encapsulates (view model), then selects the appropriate view.

There are three kinds of roles for MVC:

Model: The component used to store data (different from the domain model concept, which crosses each other)

View: A component that gets data from the model for content presentation. The same model can show different effects under different view. Gets the state of the model and does not manipulate it.

Controller: Accept and process user instructions (Operation model (business)), select a view to operate.

MVC is mainly used for the presentation layer, 3 layer is mainly used for architecture, 3 layer is generally the presentation layer, the middle tier, the data layer, wherein the presentation layer can be divided into M, V, C, (Model View Controller) model-view-controller.

The MVC pattern is a composite design pattern, an iterative solution that can be used to solve a practical problem in a specific situation. Coincidentally, he also has three things, so people have a kind of the corresponding relationship: Display layer-view; business logic layer-control; persistence layer-model. First of all, there is no obvious hierarchy between the three things in MVC, there is no obvious downward dependency, instead, the view and model are often relatively independent, and control is the bridge between the two, they are more like horizontal slicing. As a result, each block in MVC can be tested independently, whereas in a three-tier structure, the upper module's run tests are bound to provide lower-level code or piles that provide the same interface. In contrast, MVC is much more complex, but structurally clearer and less coupled.

In addition, each piece of MVC, especially inside the model, is often designed to be multi-layered. In my view of a good MVC pattern building structure, control is the core, small and stable, can be provided as a core framework, there are extensibility points, but basically can be easily configured to run without any code. The view may be a set or a variety of alternative views engine, determines the software to display the user's interface, the main work is to use the extension point and the number of different view templates as needed. Model is a business provider, which determines the functionality provided by the software, the internal may be some ordinary class or the implementation of certain interfaces of the class, in which may be different from the business color, for complex software may be divided into many layers, such as the business Logic layer, the service provider layer, the system provides layer, the data supply layer , data access layer, and so on.

Enumerate the examples in your life to specify MVC

Analogy MVC example is playing the kind of cassette game machine, control is the host, generally I buy a host on the line, as long as he is not bad, he can always let me play this kind of game. The view is the TV and the game handle, the television can work independently, he regardless of input is the television signal, the DVD player signal or the game console signal, he just displays, and he decides how we see the effect is how, if I want a bigger or the color display effect, I just need to buy a corresponding TV set on the line, the handle can also be changed, the remote bar or with vibration. The model was a game cassette, and he decided what game I was playing, whether it was the bucket or the Super Mary, and the console and the TV maker never knew what kind of game it might run on. There may be game codes and storage units in the cassette, which are designed according to the needs of the game.

Some friends refer to the interface of the cassette slot provided by the game host, in the design, sometimes also by the control provides a set of interfaces for the model or view implementation, thus forming a dependency. In general, this design is not too big problem, but will increase the coupling between the modules, but also bring some intrusion. In order to be more perfect, you can use the interface to provide the contract, can be used configuration information (or metadata information) + reflection to provide the contract, then this class interface can be degraded to as long as CLS-compliant, that is, ordinary class, like the current computer interface widely used USB, whether it is a USB flash drive, printer, Scanners or dongles, they're all normal USB devices.

Referring to the USB has a digression, the module's pluggable design or even hot-swappable design, the system can not stop the operation of the dynamic mount or remove the module, the dynamic Mount module requires the system to automatically discover new modules and according to the self-described information automatically configured, remove the possibility of a more complex, need to " Safely Remove Hardware "features similar to this.

There are many scenarios to consider when designing a broadly reusable framework to achieve greater adaptability, and the MVC pattern in general projects can be more casual.

is the relationship and function diagram of the MVC component type:

After describing the three-tier architecture and the MVC pattern, let's go back to the topic and start to explain the difference:

MVC (Model model-View view-controller controllers) is a design pattern that we can use to create a distinction between a domain object and a UI presentation layer object.

Same as the architecture level, the same thing is that they all have a presentation layer, but they differ in the other two layers.

The concept of a controller is not defined in the three-tier architecture. This is the most different place I think. and MVC does not consider the logical access of the business as two layers, which is the main difference between a three-tier architecture or an MVC build program. Of course. The model is also mentioned in layer three, but the concept of model in the three-tier architecture is not the same as the concept of model in MVC, and the typical model layer in the "three layer" is made up of entity classes, while MVC is composed of business logic and access data.

There is a clear difference between the three-tier architecture and MVC, which should be the presentation pattern (three added up and then the UI layer in the three-tier architecture)
The three-tier architecture (3-tier application) typically has a three-tier architecture that divides the entire business application into: The presentation layer (UI), the Business Logic layer (BLL), the data Access Layer (DAL). The purpose of distinguishing hierarchy is to "high cohesion, low coupling" thought.
MVC is Model-view-controller, strictly speaking, these three add up is the three layer of the UI layer in the architecture, that is, MVC in the three-tier architecture of the UI layer again differentiated, divided into the controller, view, entity three parts, the controller to complete the page logic, Through the entity to complete the call with the interface layer, and the C layer directly with the BLL in the three layer dialogue.
MVC can be a presentation layer in layer three, which belongs to the presentation layer. Layer three and MVC can coexist. Layer three is based on the business logic, and MVC is based on the page to divide.

The relationship between MVC and layer three, see:

The above is a brief introduction to the difference between the three-tier architecture and the MVC model, and if there are any questions, please criticize the advice.

Original address: http://blog.csdn.net/xjc1278003262/article/details/8870325

(turn) The difference between the three-tier architecture and the MVC pattern