Standard MVC does implement business logic directly in the controller, but in actual projects, it is still recommended to encapsulate the service layer between the controller and database operations. On the one hand, the controller responds to different request URLs, so there will be a lot of duplication in functionality; it is difficult to maintain; On the other hand, you must consider that your service functions may be exposed to other front-ends in the future, such as other application access, or different Terminals (such as APP, mobile H5, etc.); some services may even be separated and deployed independently;
It’s very bad. It’s very difficult to expand and maintainability is also very poor.
The controller should be a thin layer, and the business logic should be placed in the service layer for processing as much as possible. It should also be more free in terms of service granularity and service utilization.
Of course it’s not good. The controller layer is only responsible for business data interaction, and the business logic is handled by the service layer
The Controller layer of the project I took over now is also extremely large. One method has hundreds of lines, and there are multiple layers of if nesting. I feel that the biggest problem with this is that it will be very troublesome in later maintenance. You need to understand the previous business logic before you can change it; The method that I personally feel is better is controller-service-dao. The service is responsible for the specific logical operations. The three are called in sequence and decoupled from each other as much as possible; the code should be as extensible as possible.
Even if it is placed in service, it will still be a mess. . Still need other methods to avoid complex business situations and poor code maintainability
Let a colleague look at the code today. The first thing he said was that you should put the controller code in the service;=_=; It mainly depends on the complexity of the business. If it is a very simple business, it will not go from the controller to the service. , and then to dao; it also depends on the development specifications of the entire team;
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Standard MVC does implement business logic directly in the controller, but in actual projects, it is still recommended to encapsulate the service layer between the controller and database operations.
On the one hand, the controller responds to different request URLs, so there will be a lot of duplication in functionality; it is difficult to maintain;
On the other hand, you must consider that your service functions may be exposed to other front-ends in the future, such as other application access, or different Terminals (such as APP, mobile H5, etc.); some services may even be separated and deployed independently;
It’s very bad. It’s very difficult to expand and maintainability is also very poor.
The controller should be a thin layer, and the business logic should be placed in the service layer for processing as much as possible. It should also be more free in terms of service granularity and service utilization.
Of course it’s not good. The controller layer is only responsible for business data interaction, and the business logic is handled by the service layer
The Controller layer of the project I took over now is also extremely large. One method has hundreds of lines, and there are multiple layers of if nesting. I feel that the biggest problem with this is that it will be very troublesome in later maintenance. You need to understand the previous business logic before you can change it; The method that I personally feel is better is controller-service-dao. The service is responsible for the specific logical operations. The three are called in sequence and decoupled from each other as much as possible; the code should be as extensible as possible.
Even if it is placed in service, it will still be a mess. . Still need other methods to avoid complex business situations and poor code maintainability
Let a colleague look at the code today. The first thing he said was that you should put the controller code in the service;=_=;
It mainly depends on the complexity of the business. If it is a very simple business, it will not go from the controller to the service. , and then to dao; it also depends on the development specifications of the entire team;