Shulou(Shulou.com)06/01 Report--

This article is about what the hierarchical architecture of MVC looks like. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Traditional MVC three-tier architecture

Usually, we are used to business modeling around the data table, first design the database according to the business needs, and then complete the development of the business process.

At the implementation level, the MVC hierarchical framework is adopted, and the business data flows between the three levels (the liquidity nature of the data).

Although the MVC hierarchical design is adopted, it is still process-oriented in the implementation of the business process, which usually follows the development mode of taking data-> processing data-> storing data, which is a data-centered process idea.

You can think about it, is that how you develop your business?

Domain driven Design (DDD)

This theory puts forward a new hierarchical model, the core of which is to emphasize object-oriented.

Interfaces is the presentation layer and is still responsible for data rendering, such as rendering pages, rendering json, and so on.

Domain is the domain layer, which refers to the class encapsulation of specific entities and operations, such as order-related operations.

Application is the application layer, which assembles multiple domain to form a specific business process, such as the transaction order process, which may need to call the order, user, anti-cheating and other domain.

For orders, our traditional MVC usually treats it only as a database record, a "anemia model" in which only the attribute columns of the order are fetched from the database by calling the model layer. At the same time, we will write a service layer that encapsulates the business operation method for order records, that is, the procedural data-oriented development pattern.

Unlike DDD, it emphasizes that an order is a kind of entity, and a specific order corresponds to an order object. The order object has its own business processing methods, and the data and methods are encapsulated together.

At this point, if you need to get user information to create an order, you need the application layer to assemble it: first get the user object, and then call the method of the order object to pass in the user object to complete a process of placing the order.

Application is to do a layer of specific business processes, to assemble multiple domain.

The combination of MVC and DDD

There is no silver bullet, more reference to different ideas, the goal is how to optimize business design and customize efficient development specifications.

I feel that the essence of DDD is to bring together functions that belong to different areas, and then assemble functions in different areas in the application layer.

In contrast to our data-oriented way of thinking, it is easy to do such things: in order to achieve a cross-domain business process, we directly implement a variety of business logic in different fields, that is, the logic belonging to different fields is thrown into the application logic layer, resulting in more and more chaotic design and lower reusability.

In fact, we do not have to make full reference to DDD to transform directly into object-oriented domain design, after all, the modeling approach that the team is good at is still around data, not domain objects.

We can use DDD to optimize the hierarchical design of MVC, that is, to optimize the use of MVC from a domain perspective.

In previous days at Baidu, the company promoted the development specification of the PHP Yaf framework to mention a very important point, that is, to follow the following hierarchical design:

View

Controller

Page

Service

Model

With DDD, let's redesign what needs to be done at each layer:

Model: data reading and writing of specific domain data, such as order domain:

Generally speaking, the order is divided into the main table and the extension table, and the two tables fully express the order business, so I will implement them as a model.

Service: this layer corresponds to the model layer one by one. To put it bluntly, we regard model as the data part of the domain (pure data) and service as the method part of the domain. Together, we form entities similar to those in DDD, but we are still data-oriented and process-oriented.

Page: corresponding to the application layer of DDD, assemble multiple service to form a business process, and return the result to controller.

Controller: parse the request, assemble the parameters, call page to complete the business process, and further process the page return value into the specific appearance needed by view.

View: directly render html or Json, etc., and should not include other data processing logic.

To sum up, service+model should appear in pairs, page assembles multiple service to complete business process, and controller is just the coordinator between page and view (there should not be any business logic).

In addition, service+model should be divided by domain idea, not by data table, which can solve most of the requirements of joined tables.

For transaction requirements, the transaction switch should be controlled in the application layer, and multiple service should still be assembled to complete intra-transaction operations to ensure clear boundaries in different areas.

Thank you for reading! This is the end of this article on "what is the hierarchical architecture of MVC?". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.