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?

  • @sugar_in_your_tea
    link
    112 months ago

    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.

    • @[email protected]
      link
      fedilink
      4
      edit-2
      2 months ago

      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
        link
        22 months ago

        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.

        • @[email protected]
          link
          fedilink
          12 months ago

          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.