3 ms·
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
by 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 agoThis 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 agoWhat, then, is a service other than a model without a database table?
- regularfry 3y agoEh? 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.