Yii2 Framework, is it necessary to separate the service layer?

In the current project, the service layer is using static method calls, and then instantiating the AR model within the method

In the YII2 auto-generated template, the AR model is used directly in the model.

It doesn't make much difference, what is the meaning of separating the service layer?

Reply content:

In the current project, the service layer is using static method calls, and then instantiating the AR model within the method

In the YII2 auto-generated template, the AR model is used directly in the model.

It doesn't make much difference, what is the meaning of separating the service layer?

In a simple system, layering is like this.

Controller <-> Model <-> storage (SQL, NoSQL, cache)

All the business logic is on the model

Now discuss a common scenario where the user orders to buy something, the business logic involved in the model class has user (user), order (orders), Goods (product)

What about placing an order on the user or order? This business logic requires the participation of multiple model classes, whether placed on user or order

The need for more and more in the system, you will find that you always have a few model in the continuous expansion, these model even produced a network of inter-dependency relationship

The more complex the requirements, the more likely you are to get into this mess.

The service layer's role is to encapsulate these complex business logic that requires multiple model participation, which no longer has a direct dependency between the model, but rather a collaborative completion of the logic within the service layer

The first goal of a service layer is to decouple the model layer.

The industry of the previously mentioned model of the swelling is called "congestion model", the initial reflection of the congestion models of a solution is the "anemia model", the model inside as little logic, the logic is moved to the controller level to deal with, In the controller, multiple model is called to complete the business logic, and it also achieves the function of decoupling between model.

But the problem is that the business logic is put on the controller level, if the other controller also needs the same business logic, only in the controller to invoke the other controller, it is inconvenient and troublesome

So then the decoupling was put on a separate layer, called service, now layered into this

Controller <-> Service <-> model <-> storage

The second function of a service layer is to reuse

That's pretty much it.

Simple rough Summary, if you have a business logic, need to use more than one model, put into the service layer, if only this model of their own things, and other model has nothing to do with the model is good.

If your system is small, the business logic is super simple, and there is no need for long-term evolutionary iterations, you can do whatever you like.

Depends on whether the model layer is messy enough .

Should not be separated out of the new layer, there is no service layer has its own advantages, no pros and cons .

If you mess up, don't mess up, just look at the appropriate .

If it is really messy, non-split, presumably the Lord will not ask questions again, so speculate now is just beginning Chaos .

If so, in fact this is the beginning of Chaos , recommend the demolition now .

Layering is always an effective means of dealing with complex business (general project three level, complex project back to four layers, five layers).

In Oo-oriented systems, the service is the Biz Manager, and the service is a TS script in a process-oriented system.

AR model can of course put business code, but only to operate the model itself (if the use of repository can not operate the same type of model, but should operate in the repository of a class of models), not other types of model dependent.

Business Manager (also known as service) handles the relationship between different types of model or repository, depending on the business.

When the business is more complex, you can pull out the facade façade of the subsystem and handle the order of different business manager calls.

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

All the projects I've touched are in these layers, and the complexity is facade. Small projects are, of course, thrown directly into the model, and as the business continues to complicate, all we have to do is refactor.