Web three-tier architecture and MVC

The web three-tier architecture refers to:

• > User Interface layers (UI layer)
• > Business logic layers (bussiness layer)
• > Persistence layer

About business logic and user interfaces

In the early web development, because the business is relatively simple, there is no three-tier division. The presentation of user data and the receipt, encapsulation, validation, processing, and operation of the database are all placed in JSP pages. At this time of development, like Pangu has not yet epoch-creating, the entire Web development is a "chaos." As businesses become more complex, people are starting to think better of using OOP as a razor to solve problems. It was found that the business logic was extracted and formed a layer unrelated to the display and persistence, which made the business logic clear and the product easier to maintain. This is how Sun pioneered the JSP Model 1 development.

About persistence

In the JSP M1 development approach, there is no recommendation for how data is persisted. In many companies, their products are architected and designed in a database-centric architecture. In their products, although there are DAO layer, but the responsibility is unclear. Why do you say that, because I found that in many people's eyes, the DAO layer of the accusation is very simple-delete and change. But I think this understanding is actually putting the cart before the horse. For simple data management, this understanding is understandable. But as business logic becomes increasingly complex. We're really having a headache with complex object relationships, and if we're going to be thinking about how to store the data (usually in a relational database), we're starting to complain that the architecture of our software is disgusting and messed up. The idea of object-oriented design teaches us--if we don't want to do it, give it to someone else! Then the smart architects put forward a concept-persistence. If we add a new layer in our own application--specifically responsible for persisting and synchronizing the state of the object--Is it possible to "engage the object" wholeheartedly? The persistence concept represents a reduction in our reliance on relational databases. So it was even inferred that the database was dead. At the same time, the new concept of relational database has been formed and evolved into theory, and the product is derived from theory. So a well-conscious programmer, at least, should agree that persistence is not the most important part of the product-the most important part is clear and correct business logic.

Grey area

Yes, in theory, the Web three-tier architecture is beautiful. But in the actual development of the product, we found a lot of problems. The main problem is that there are many gray areas between the UI layer and the business layer . These gray areas of the business logic layer do not want to tube, the UI layer does not want to tube. Let's give some examples:

Example 1, a page jump relationship that is difficult to manage

I was talking about a JSP course, a simple case of a page jump graph. This is a very simple example, but the page jump relationship is quite complicated. Imagine how complicated this picture would be if you were doing a product with hundreds of tables, more than 10 core modules, and hundreds of pages! The problem is that these page jump relationships are scattered across JSPs and servlets and are very difficult to manage.

Example 2, validation and encapsulation of the form data:

Let's say we're doing a simple form submission, and we want to validate and encapsulate the data for the user, and ultimately give it to the business logic layer as an entity object. From the three-tier architecture analysis, the thing we want to do is this:

But who does the work of validating and encapsulating the data be handed over to? The UI layer or the business logic layer? It's not all right!

Example 3, internationalization:

If we want to provide different languages for people in different countries and regions, there is no doubt that international support is needed. Then, we need to determine in the JSP page which language should be presented to the user based on the user's configuration or request information. And should these judgments and display logic be divided into the business logic layer or the UI layer?

Solve the problem with the idea of MVC

For the tangled problem, we always have to find a way to break it down. MVC is a design idea. This idea emphasizes the separation of the implementation model, view, and controller. How does this idea work on the Web? In fact, we introduce MVC in Web development, and want to achieve the goal is to achieve the UI layer and the business Logic layer separation-controller is to achieve the above purpose exists!

After solving the persistence problem, we found that what we call the business logic layer and the model in MVC refers to one thing, what we call the UI layer and the view in MVC is one thing. MVC provides the idea of separating the model from the view-the introduction of the controller. We put the page Jump Relationship management, form data encapsulation and verification, internationalization and other tasks to the controller processing. Therefore, it is not difficult to understand why the popular MVC framework has management page jump relationships, form data encapsulation and validation, internationalization and other characteristics.

Summarize

In Java Web Development, the MVC Framework acts as an adapter for the UI layer and the business logic layer. The MVC framework implements the maximum separation between the UI layer and the business logic layer.

Web three-tier architecture and MVC