vendredi 12 mars 2021

Why do all the backend developers choose controller-service-repository pattern?

Why not just router + handler + single_instance_db_pool pattern?

Many people around me say the controller-service-repository pattern is MVC.

As far as I know, the pattern MVC(model view controller) is just used for UI programming. UI programing needs states of tree shape, MVC fits it well.

But doesn't the backend programing have no state? HTTP is a stateless protocol. Yeah we have session, database to store the state, but they are totally different from UI state which is in a tree shape.

The UI state machine accept messages from anywhere include trunk/branch/leaf of the tree, and it needn't to worry about concurrency.

The backend state machine accept messages from just one point, then split by the router, it's flat.


Then if the controller-service-repository pattern is not something like MVC, why do people use it?

In my opinion, oop class is used to create a state machine, so things like React suits it well, but things like controller/service/repository have not state, we usually use it just for its static functions even though we didn't add the static keyword. Don't you declare them singleton scope in Spring?

Sorry, I didn't ask a very clear question. I just think the backend development should be a request context flowing through a series of utils functions then getting the response, rather than so many concepts controller, service, repository, DI and many others.

Aucun commentaire:

Enregistrer un commentaire