Introducing service Layer in MVC is a good solution [recommended]

MVC is a common program structure in web development.

The simple mvc structure is as follows:

View layer: Display layer.

Control Layer: business layer, which combines various actions.

Model layer: model layer. It generally deals with data. Simple sample: a table corresponds to a model class.

The control layer calls the model layer method to access data.

To a certain extent, the code can be clear, easy to expand, and the complexity of code management is low.

However, if there are many businesses and complicated logic websites, and the levels of developers are uneven, it will inevitably lead to the following situation:

The code in 1action is getting longer and longer, and the logic is getting more complicated. There seems to be a lot of reusable code between different actions, but it is very difficult to refactor the code.

The 2model layer contains more and more methods, and some methods are too complicated. Even many methods contain business logic.

3. The code is changed.

4. It is difficult to perform automated testing on the code.

I thought that the introduction of mvc would leave the management complexity of the program unworried, but now I am faced with the same problem.

According to my recent studies, the introduction of the service layer in mvc can greatly avoid or mitigate the above problems.

The original mvc structure is changed to the following:

1view layer: Display layer.

2control layer: business layer, which combines various actions.

3service layer.

4DAO layer.

The original model layer disappears and the service layer and DAO layer are added. DAO, that is, Data Access Object, Data Access interface, and Data Access: As its name implies, it deals with databases.

In this structure, control does not directly contact DAO,

When data needs to be operated, the DAO layer is accessed through the service layer.

The service layer does not only call DAO to operate data, but also contains certain business logic. The design of the entire program has also become a service-oriented design.

The benefits of doing so are:

The action in the 1control layer can be simplified because some logic in the action is duplicated into services. Different actions can also be reused.

2. The DAO layer that is only responsible for dealing with data can also be simplified compared to the previous model layer (the DAO layer should only perform the most atomic data operations as much as possible, and the relationship between different data operations, this is the service layer ).

The 3service layer can achieve code reuse to a large extent, and the functional encapsulation of programs is clearer.

4. Because the service layer clearly defines the boundaries of applications, it is much easier to perform automated testing for each service function (corresponding to a service/application. How can WEB programs perform unit tests conveniently? This is a problem that has always plagued me. Such a design seems to be really feasible ~

5. In theory, the assignment of developers can be divided by hierarchy. Theoretically ~

At the same time, such a design model also has some shortcomings:

There are too many layers, and developers who are new to it are time consuming to understand the simple mvc structure;

The design of the service layer requires some skill, because the logic of the action and the model layer is largely transferred here.

But on the whole, the introduction of service Layer makes the application boundary clearer and provides a series of reusable operation sets. This is very helpful for the scalability and maintainability of websites.

Of course, if the business logic of the website is not complex, there is no need to use such design. Over-design is the source of all evil ~