The difference between MVC and three-tier architecture

the difference between the MVC pattern and the three-tier architecture

Always confuse the MVC performance pattern with the three-tier schema pattern, for this record.

three layer architecture and MVC are clearly different, MVC should be the presentation mode (three add up is the UI layer in the three-tier architecture) three-tier architecture (3-tier application) The usual three-tier architecture is the division of 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. 1, the presentation layer (UI): Popular speaking is to show the user interface, that is, users in the use of a system when he saw the gains.     2, Business logic Layer (BLL): The operation of the specific problem, it can be said that the operation of the data layer, the data business logic processing.     3, data access Layer (DAL): This layer of transactions directly manipulate the database, for data additions, deletions, modifications, updates, lookups and so on.  
MVC is Model-view-controller, strictly speaking, these three add up is the UI layer in the three layer architecture, that is, MVC divides the UI layer in the three-tier architecture again, divides into the controller, the view, the entity three parts, the controller completes 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 framework in layer three, belong 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. 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) models-view-controller  

I had confused the concept of the MVC pattern with the three-tier structure in web development until today and found that it was my understanding. The MVC pattern is the guide mode of GUI interface development, and the program is divided into three parts based on the thought of the separation of the presentation layer: Model-view-controller, triangular structure. Model refers to the data and application logic, which is the view of the model, which is the user interface. Both are well understood, and the key point is the controller's role and the relationship between the three. In the MVC pattern, the controller and view belong to the presentation layer, which usually appears in pairs. A controller is designed to handle the logic of user interaction. A common misconception is that the controller is responsible for dealing with the interaction between the view and model, whereas the view and model can actually communicate directly. Because user interaction usually involves model changes and view updates, these can be considered side effects of the controller.
MVC is the architecture of the presentation layer, and MVC's model is actually ViewModel, which is the data for the view to show. ViewModel does not contain business logic, nor does it 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 (ViewModel), then selects the appropriate view.
MVC exists in the desktop program, m refers to the data model, v refers to the user interface, C is the controller. The purpose of using MVC is to separate the implementation code for M and v so that the same program can use a different representation. For example, a batch of statistical data can be represented by a histogram, pie chart, respectively. C exists to ensure the synchronization of M and V, and once M is changed, V should be updated synchronously. How MVC works MVC is a design pattern that makes it mandatory to separate the input, processing, and output of an application. Using an MVC application is divided into three core parts: model, view, controller. Each of them handles their own tasks. The View v view is the interface that the user sees and interacts with. For older Web applications, views are an interface of HTML elements, and in modern Web applications, HTML still plays an important role in the view, but new technologies are emerging, including Macromedia Flash and Image xhtml,xml/xsl , WML, and some other identity languages and Web services. How to handle an application's interface becomes increasingly challenging. One big benefit of MVC is that it can handle many different views of your application. There is really no real processing happening in the view, whether the data is stored online or an employee list, as a view, it is simply a way to output data and allow the user to manipulate it. The model M model represents enterprise data and business rules. Of the three parts of MVC, the model has the most processing tasks. The data returned by the model is neutral, meaning that the model is independent of the data format, so that a model can provide data for multiple views. Because the code applied to the model can be reused by multiple views only once, it reduces the repetition of the code. The Controller C controller accepts the user's input and invokes the model and view to complete the user's needs. So when you click a hyperlink in a Web page and send an HTML form, the controller itself does not output anything and do any processing. It simply receives the request and decides which model component is called to process the request, and then determines which view to use to display the returned data.
The model model is the main part of the application. Models represent business data, or business logic. Implementation of the specific business logic, state management functions. View view is a part of the user interface in an application that is the interface that the user sees and interacts with. is the page that interacts with the user, usually realizes the input and output function of the data. Controller controller controllers work to control user interface data display and update model object status according to user input. Play the role of controlling the whole business process, and realize the collaborative work between view layer and model layer.
3-tier architecture refers to: Presentation layer (display layer) business logic Layer data access layer (persistence) if you have to "mechanically" it with MVC, then I'm going to have to "twist this melon" here. That is, the "presentation layer" ASPX page in the V 3-tier architecture corresponds to the view in MVC (different inherited classes) C three layer architecture in the "Presentation Layer" Aspx.cs page (class) corresponding to the controller in MVC, it is not difficult to understand this, we think of the Redirect we have written before, of course, it is to jump to some of the link page, and the controller in MVC to do more cool , it controls and displays a view of the output. That is, the function is to control the business process and display information, but the means of implementation are different. The business logic layer and data access layer in the M 3-tier architecture correspond to the model in MVC (must view and controller have found the "husband's" model can only be the business logic layer and the data Access layer)
Why use MVC most Web applications are created using a process such as asp,php, or CFML, which has been fully supported by the object-oriented model since the PHP5.0 version. They mix data-tier code like database query statements with presentation layer code such as HTML. The more experienced developers separate the data from the presentation layer, but this is often not easy to do and requires careful planning and ongoing attempts. MVC is fundamentally mandatory to separate them. Although it takes some extra work to construct an MVC application, the benefits it brings to us are no doubt. First, the most important point is that multiple views can share a model, and now more and more ways to access your application. One solution to this is to use MVC, whether your users want a flash interface or a WAP interface, and use a model to handle them. Since you have separated the data and business rules from the presentation layer, you can maximize the reuse of your code. Since the data returned by the model is not formatted, the same artifacts can be used by different interfaces. For example, many of the data may be represented in HTML, but they may also be represented by Adobe Flash and WAP. The model also has the capability of state management and data persistence processing, for example, session-based shopping carts and e-commerce processes can also be reused by flash sites or wireless networking applications. Because the model is self-contained and detached from the controller and view, it is easy to change the data layer and business rules of your application. If you want to port your database from MySQL to Oracle, or change your RDBMS-based data source to LDAP, just change your model. Once you've implemented the model correctly, the view will display them correctly, regardless of whether your data comes from a database or an LDAP server. Since the three parts of an application using MVC are independent, changing one does not affect the other two, so you can construct good loosely coupled components based on this design idea. For me, the controller also provides the benefit of using a controller to join different models and views to complete the user's needs, so that the controller can provide a powerful means of constructing the application. Given some reusable models and views, the controller can select the model to process based on the user's needs, and then select the view to display the processing results to the user.
take a simple login module, said, the requirement is that you enter a user name, password, if the input is the same as predefined, then go to the correct page, if not the same, prompted an error message "You y don't put me here, the wrong input!" ”。 V in this small module, the beginning of the user name password to enter the page and the page after the check is the equivalent of view C and here also need a controller page, is used to receive input user name password, There is a FLG returned after the calibration (this FLG is used to determine whether you entered the correct, and jump to the corresponding page) M finally missing a model, then you are the class used for verification, he is to deal with your input is not the same as pre-ordered, and then return to a FLG. This completely realizes the separation between the logic and the page, my page no matter what you do, I will be a display, and controller also regardless of your model how to judge right, anyway, I gave you the user name and password, you have to give me the whole back to a flg, and medol it, Anyway, you can give me a username and password, and I'll give you a whole FLG.
m provides data, relationships between data, conversions, etc. And you can tell the view and controller where they have changed. V provides display, can update itself according to m changes C For example, the view does a click of a button, will be sent to the controller of the view, and then this controller to decide what to do (let the model update data, control the view changes) MVC is a composite mode MV,MC is the component combination mode inside the Observer pattern m VC is a strategy mode (can change different controllers at any time)

The MVC pattern was introduced in the 70 's and was originally used on the Smalltalk platform. MVC is the expression pattern, which is used to show the user the many forms of the build (Ui/presentation Patten) MVC has three roles: Model: The component used to store the data (unlike 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 Overview: There are one-way references to collaboration, such as model does not know the presence of view and controller. View does not know the existence of a controller. This isolates performance and data. View and controller are one-way references. In fact, the view and controller also have data interaction.

The important feature of MVC is separation. Two separations: the separation of view and data (model) uses different view to present the same data, separates the visible and invisible components, and can independently test the model. Because separating the visual components reduces the external dependencies to facilitate testing. (The database is also an external component) the separation Controller of view and Representation logic (Controller) is a component of performance logic, not a business logic component. MVC can be used as a pattern of expression as well as a constructive pattern, meaning that the controller can also be a business logic. Separate logic and concrete presentation, allowing for independent testing of logic.

is MVC and three-tier architecture similar to the three-tier architecture?   View-ui Layer |  Controller-bussiness Layer | Model-data Access Layer In fact this is the wrong MVC is the expression pattern (Presentation pattern) Three-tier architecture is a typical schema pattern (Architecture pattern) Three-tier architecture is a typical up-down relationship, The upper layer relies on the lower layer. But MVC, as a performance model, does not exist in the upper and lower relations, but is a collaborative relationship. Even if MVC is used as an architectural pattern, it is not a layered pattern. MVC and the three-tier architecture are basically not comparable and are applied to different areas of technology.

MVC mode with three-tier architecture:

UI (View) ← (contorller) (display layer)

***********************

BLL (model) (Business logic Layer)

***********************

Dal (model) (Data processing layer)

The difference between MVC and three-tier architecture