Is it necessary to separate the service layer in the Yii2 framework?

In the current project, the service layer is called using static methods, and armodel is instantiated in the method. In the template automatically generated by Yii2, armodel is directly used in the model. There is no big difference between the two. What is the significance of separating the service layer? In the current project, the service layer is called using static methods, and the ar model is instantiated in the method.

In the template automatically generated by Yii2, the ar model is directly used in the model.

There is no big difference between the two. What is the significance of separating the service layer?

Reply content:

In the current project, the service layer is called using static methods, and the ar model is instantiated in the method.

In the template automatically generated by Yii2, the ar model is directly used in the model.

There is no big difference between the two. What is the significance of separating the service layer?

In a simple system, layers are like this.

Controller <-> model <-> storage (SQL, nosql, cache)

All business logic is on the model.

Now we will discuss a common scenario where users want to buy something to place orders. The business logic involves the following model classes: User, Order, and Goods)

So is the Order placed on the User or Order? Whether put on the User or Order, this business logic requires the participation of multiple model classes.

This kind of requirement is increasing in the system, and you will find that there are always a few models that are constantly expanding, and these models even have a net-shaped dependency relationship.

The more complex the requirements are, the more likely you are to fall into this chaotic situation.

The role of the service layer is to encapsulate the complex business logic that requires multiple models to participate. These models do not directly depend on each other, but collaborate to complete the logic in the service layer.

The first purpose of the service layer is to decouple the model layer.

The industry calls the above-mentioned ever-expanding model A "congestion model". One solution for reflecting on the congestion model at first is the "anemia model", where the model should put as little logic as possible, moving these logics to the controller layer for processing, calling multiple models in the controller to complete the business logic also achieves decoupling between models.

But the problem is that the business logic is put at the controller level. If other controllers need the same business logic, they can only call other controllers in the controller. this is inconvenient and troublesome.

So we put this decoupling on a separate layer, called service. Now the layer is like this.

Controller <-> service <-> model <-> storage

The second role of the service layer is reuse.

This is almost the case.

Simply and roughly speaking, if you need to use multiple models for a certain business logic, put them in the service layer. If it's just about this model, it has nothing to do with other models. Just put it in the model.

If your system is small, your business logic is simple, and there is no need for long-term evolution iteration, you can do whatever you like.

Depends on the model layerMessy?.

This should not separate the new layer, whether or not the service layer has their own advantages, noAdvantages and disadvantages.

If it is messy, just remove it.Suitable or not.

If it is really messy and non-sharding is not necessary, the subject will not ask any more questions, so I guess it isFirst chaos.

If so, this is the beginning.ChaosNow,We recommend that you split it now..

Tiering is always an effective means to process complex services (generally three layers of projects return to four or five layers of complex projects ).

In OO-oriented systems, service is biz manager, and in process-oriented systems, service is a TS script.

Business Code can be stored in the AR Model, but only the model itself can be operated (if repository is used, the model of the same type cannot be operated, but a certain type of models should be operated in repository ), does not generate dependencies for other types of models.

The service manager processes the relationship between different types of models or repository based on the service.

When the business is more complex, you can extract the facade of the subsystem to process the calling sequence of different business managers.

Finally, call them in the controller (yes, the controller can also be considered as a facade ).

All the projects I have come into contact with are in these layers, and the complexity of the projects is the result of facade. Of course, small projects are directly thrown into the model. As the business continues to be complicated, all we have to do is rebuild constantly.