I think I saw this early on, but then forgot about it. Stumbled upon it today, and it actually looks like a cool project. Have anyone any experience of using it for a real or just a toy project?

you are viewing a single comment's thread
view the rest of the comments

[–] sugar_in_your_tea@sh.itjust.works 11 points 7 months ago (1 children)

We are moving to the controller-service-repository pattern for our backend services. Basically:

controller - handles user input, calls services, formats responses
service - business logic
repository - database access

This makes the code a lot more testable.

Our frontends basically do React-style MVC, which helps reduce bugs from internal state not matching the model.

[–] Lmaydev@programming.dev 4 points 7 months ago* (last edited 7 months ago) (1 children)

Tbh that's essentially what we do. Just with a mediator between the controller and services. Maybe a better name for it.

[–] sugar_in_your_tea@sh.itjust.works 2 points 7 months ago (1 children)

Ok, so it sounds like our controller is doing the mediator role, and our web framework (with the middleware and whatnot) is doing your controller work.

Our project is in Python with Flask, and Flask + middleware handles general stuff (authentication, parsing headers, etc), which is common for most requests, and then the controller loads the metadata into structures (JSON, query params, etc) with basic validation (ranges, values for enums, etc), and the service takes it from there.

[–] Lmaydev@programming.dev 1 points 7 months ago (1 children)

AspNetCore works very much the same.

The mediator pattern is a little different though. It doesn't talk to the service directly.

The controller creates a request object and passes it to the mediator. The mediator finds the correct handler and invokes it. The result is then returned to the controller.

It essentially completely decouples the controller from the service.

[–] sugar_in_your_tea@sh.itjust.works 1 points 7 months ago

Ah, makes sense. Thanks!