MVC View page requires multiple model, processing of complex web pages

Requirements Description

A more complex page, the interface contains the element data from a number of related or unrelated tables, and then we have to do is to present the data on the interface.

That's probably what they did 10 years ago.

Write a complex SQL statement directly, return a two-dimensional table that contains the data you want, and then start binding directly to the interface.

Simple, rough.

Today's situation

The popularization of information-based solutions, many of the enterprise applications we received are in the old system can not meet the needs of the expansion of the situation, the business functions will be built on the original basis becomes more complex.

Therefore, in order to solve the confusion caused by the complexity of the system, people began to use layered architecture.

The data access layer is separated so that the data provision can be reused. Separate the business logic layer to make the business logic reusable.

The complexity of the business has led to the popularity of domain-driven design, which brings more business logic within the domain model, allowing more business logic to be reused.

Raises the question

1, many people use the ORM tool, think it can only deal with simple functions, or think it is suitable to do only a single table on the interface to modify and delete, in short, think it is not flexible, in fact, ORM tool model is only a business layer of things, not the model of the presentation layer.

2, encountered this interface element complex problem, it feels that layered architecture is simply a rip, there is a need to directly come up with a SQL statement to solve the problem of the impulse.

How do we fix this?

1, the interface elements with a single entity corresponding to the situation.

This is often the case in Microsoft's official demo, ASP. NET MVC 5+ef6 can automatically generate additions and deletions to the list of 3 pages, nothing to say.

It is often easy to mislead us that the M in MVC refers to the entity class, in fact, M can also refer to the entity's service class, the entity's service class contains the processing of business logic.

In fact, M refers to the business logic layer, does not necessarily contain only a single entity, it is likely that there are many associated entities, or called aggregate root.

2, the interface element with a number of related entities corresponding to the case.

This is the aggregation root mentioned above, the business layer contains some logic, and finally returns an aggregate root to the controller (C).

A view can be done with just one model, and a strong type makes it easy to point out its dependencies.

Let the business layer do what it should do, and don't let the controller of the performance layer rob the business layer of the job.

3, more complex points, interface elements with a number of unrelated entities corresponding to the case.

In this case, we need to create a viewmodel and then use it to assemble multiple unrelated entities.

Grasp a principle, the business class corresponds to the business model, ViewModel corresponds to each view.

Therefore, the above two processing methods are simply the interface elements to alleviate the workload of the practice, and theoretically need a view pair should have a viewmodel.

4, a little more complicated, or more than a little.

Well, it's really complicated enough, so ignore all the theories, native SQL, stored procedures, no layering, whatever.

The business logic is written in the database, or written in the application, depending on the vertical load balancing, requiring wisdom and experience.

The topic is the presentation layer, so it's not a question of whether the database should handle business logic.

Summarize:

When the interface element is more complex, try to create a viewmodel to combine the business class to sharpen it, rather than complaining about MVC, ORM, layered architecture is not flexible enough.

This article reproduced from Yan 13 's blog

Original title: Presentation layer Design (ii)--MVC How to handle complex interface elements

MVC View page requires multiple model, processing of complex web pages