5 ms·

We really need to call it Model-View-Controller-Service-Repository and be done with it. That is actually what happens 99% of the time. Logic is done within ser

We really need to call it Model-View-Controller-Service-Repository and be done with it. That is actually what happens 99% of the time. Logic is done within services and where the complex dependency graphs live. Repositories do the data retrieval. The controller is a traffic cop. The model is a data transfer object with maybe some calculated fields. The view makes things pretty.

gabereiser 3y ago
Lol, but MVCSR (MVCaeser) sounds like an architectural dictatorship where one must follow all rules or else be outcast from citizenship. Where some executive will stab you in the back and sell it to a private equity firm to be cut and squeezed by all the lands and your intentions and beautiful code structure is murdered by junior bootcamp devs. /s
- LeonB 3y ago
  The problem with the MVCaesar pattern is that sooner or later a Basic Routing Universal Transformer User Service stabs it in the back.
  - gabereiser 3y ago
    Ironically named Optimus.
- IggleSniggle 3y ago
  Not a MCSVR (McServer)?
nightpool 3y ago
No, please for the love of god stop writing services. Having random grab-bags of methods makes it infinitely harder to find what code lives where, instead of putting it into models where we have 20+ years of OO design principles (single responsibility, open to extension, liskov substitution, interface segregation, etc) to guide us. "Fat models, skinny controllers" is a Rails guiding principle for a reason
- ebiester 3y ago
  Until the moment that models have to call other models to get anything done. The problem is that the models often get too tied with the database implementation. Then, you're separating business logic that doesn't make sense to separate. The fat model ruins single responsibility because the database table is not a good proxy for one reason to change.
  - LeonB 3y ago
    > models have to call other models. “You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"
  - deleted 3y ago
    [deleted]
  - regularfry 3y ago
    This is a specific problem with the Active Record pattern, rather than something intrinsic to MVC, and it's exactly why AR is fine for simple apps where the business logic looks a lot like manipulating a row in a database, but breaks down for anything more involved. But also there's no reason you can't have non-database-backed classes sat next to AR models, if they make sense in the domain. Not everything needs to be a database row.
    - ebiester 3y ago
      What, then, is a service other than a model without a database table?
      - regularfry 3y ago
        Eh? It's a service. It represents a domain operation (or group of operations) that hasn't been coalesced into either a value type or a transient entity, both of which are also models without database tables, both of which are preferable to a service if they fit the domain. None of this says that putting business logic into a separate class to the thing that happens to back onto a database row is correct because of single responsibility. That's a fundamental misunderstanding of the SRP.
KronisLV 3y ago
> Model-View-Controller-Service-Repository Where would you put validation logic, though? I mean, some of it might need to just check whether a domain object has its fields filled out, but other validations might need to cross reference DB data to make sure that everything is valid in accordance to the business rules. Ergo, we might have Model-View-Controller-Service-Repository-Validator Even without being silly, it's interesting to see how different languages and frameworks handle common concerns, for example, with some you will have repositories, with other the model objects themselves will handle queries through some ORM.
- pravus 3y ago
  Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. It's not always possible to front-load that into a simple schema in your transports and each component needs to be correct in its own domain.
  - KronisLV 3y ago
    > Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. While it certainly isn't always possible, I've definitely seen it be aggregated in a single place in monolithic codebases that focused on CRUD. Essentially, it was structured like so: +--------------+ +------------------------+ +-------------+ |Resource (API)|---|Service (business logic)|---|DB Repository| +--------------+ +------------------------- +-------------+ | \ +-----------------------+ \ +-----------------+ |Validator (validations)| \|REST clients etc.| +-----------------------+ +-----------------+ The Resources were typically just API endpoints (HTTP), that passed data onwards to Services. Those could then call upon other services or service requests on their own: store/persist data with Repositories, deal with scheduled processes, or pass data on to other systems through REST clients etc. Before Services did any of those, they reached out to a Validator to make sure that the data matches the business rules and constraints. Sometimes there was additional validation context passed in (essentially a map and some enums), sometimes there were certain constraints that an entity needed to always follow within the context of the business and so on. In practice, it was good because you could see all of the constraints in one place, that an entity has to match before it can be persisted in the DB, or passed onwards to another system. But then again, that's not always viable in more modern architectures. Of course, it wasn't the most traditional approach to MVC either, even if those concepts translate pretty well to it.

gabereiser 3y ago

Lol, but MVCSR (MVCaeser) sounds like an architectural dictatorship where one must follow all rules or else be outcast from citizenship. Where some executive will stab you in the back and sell it to a private equity firm to be cut and squeezed by all the lands and your intentions and beautiful code structure is murdered by junior bootcamp devs. /s

LeonB 3y ago
The problem with the MVCaesar pattern is that sooner or later a Basic Routing Universal Transformer User Service stabs it in the back.
- gabereiser 3y ago
  Ironically named Optimus.
IggleSniggle 3y ago
Not a MCSVR (McServer)?

nightpool 3y ago

No, please for the love of god stop writing services. Having random grab-bags of methods makes it infinitely harder to find what code lives where, instead of putting it into models where we have 20+ years of OO design principles (single responsibility, open to extension, liskov substitution, interface segregation, etc) to guide us. "Fat models, skinny controllers" is a Rails guiding principle for a reason

ebiester 3y ago
Until the moment that models have to call other models to get anything done. The problem is that the models often get too tied with the database implementation. Then, you're separating business logic that doesn't make sense to separate. The fat model ruins single responsibility because the database table is not a good proxy for one reason to change.
- LeonB 3y ago
  > models have to call other models. “You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"
- deleted 3y ago
  [deleted]
- regularfry 3y ago
  This is a specific problem with the Active Record pattern, rather than something intrinsic to MVC, and it's exactly why AR is fine for simple apps where the business logic looks a lot like manipulating a row in a database, but breaks down for anything more involved. But also there's no reason you can't have non-database-backed classes sat next to AR models, if they make sense in the domain. Not everything needs to be a database row.
  - ebiester 3y ago
    What, then, is a service other than a model without a database table?
    - regularfry 3y ago
      Eh? It's a service. It represents a domain operation (or group of operations) that hasn't been coalesced into either a value type or a transient entity, both of which are also models without database tables, both of which are preferable to a service if they fit the domain. None of this says that putting business logic into a separate class to the thing that happens to back onto a database row is correct because of single responsibility. That's a fundamental misunderstanding of the SRP.

KronisLV 3y ago

> Model-View-Controller-Service-Repository Where would you put validation logic, though? I mean, some of it might need to just check whether a domain object has its fields filled out, but other validations might need to cross reference DB data to make sure that everything is valid in accordance to the business rules. Ergo, we might have Model-View-Controller-Service-Repository-Validator Even without being silly, it's interesting to see how different languages and frameworks handle common concerns, for example, with some you will have repositories, with other the model objects themselves will handle queries through some ORM.

pravus 3y ago
Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. It's not always possible to front-load that into a simple schema in your transports and each component needs to be correct in its own domain.
- KronisLV 3y ago
  > Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. While it certainly isn't always possible, I've definitely seen it be aggregated in a single place in monolithic codebases that focused on CRUD. Essentially, it was structured like so: +--------------+ +------------------------+ +-------------+ |Resource (API)|---|Service (business logic)|---|DB Repository| +--------------+ +------------------------- +-------------+ | \ +-----------------------+ \ +-----------------+ |Validator (validations)| \|REST clients etc.| +-----------------------+ +-----------------+ The Resources were typically just API endpoints (HTTP), that passed data onwards to Services. Those could then call upon other services or service requests on their own: store/persist data with Repositories, deal with scheduled processes, or pass data on to other systems through REST clients etc. Before Services did any of those, they reached out to a Validator to make sure that the data matches the business rules and constraints. Sometimes there was additional validation context passed in (essentially a map and some enums), sometimes there were certain constraints that an entity needed to always follow within the context of the business and so on. In practice, it was good because you could see all of the constraints in one place, that an entity has to match before it can be persisted in the DB, or passed onwards to another system. But then again, that's not always viable in more modern architectures. Of course, it wasn't the most traditional approach to MVC either, even if those concepts translate pretty well to it.