4 ms·

Def 2 is actively bad and wrong, though. It happens to fit simple apps (and simple bits of complex apps) so it looks reasonable, but what's really needed is a

Def 2 is actively bad and wrong, though. It happens to fit simple apps (and simple bits of complex apps) so it looks reasonable, but what's really needed is an off-ramp to let the model actually be what it should be, which is a domain object. Active Record is an optimisation that by rights ought to be premature, but the downsides don't start to bite until a certain complexity threshold which a lot of apps might just never hit.

ysavir 3y ago
> Def 2 is actively bad and wrong, though. It happens to fit simple apps (and simple bits of complex apps) so it looks reasonable, but what's really needed is an off-ramp to let the model actually be what it should be, which is a domain object. I somewhat agree. The problem, I think, is that MVC is great at explaining the types of contributing code to a software project, but it doesn't lend well to a directory structure in a project. There are just so many more models compared to controllers/views that it's logical to make each type of model object be its own top-level directory, along with controllers and views (well, top level within an `app` directory, as is custom in a Rails project). So you end up in situations where people either have a "Model(record)/Service/Decorator/OtherModelPattern/OtherModelPattern/OtherModelPattern/Controllers/Views" system, a system where all the domain logic is put into ORM classes, or a system where all models are organized within the `models` directory, but possibly interfering with the intuitive file lookup of the framework (eg, if you tried putting all active record models in an `app/models/records` directory and having a huge break from Rails tradition). If Rails simply used "Record" instead of "Models" for the directory name, a lot of this could be a lot clearer, but we're now what, 18 years deep into the muddying of the MVC waters? As much as I'd love to see a return to using MVC properly, I'd rather concentrate on doing more productive things.

ysavir 3y ago

> Def 2 is actively bad and wrong, though. It happens to fit simple apps (and simple bits of complex apps) so it looks reasonable, but what's really needed is an off-ramp to let the model actually be what it should be, which is a domain object. I somewhat agree. The problem, I think, is that MVC is great at explaining the types of contributing code to a software project, but it doesn't lend well to a directory structure in a project. There are just so many more models compared to controllers/views that it's logical to make each type of model object be its own top-level directory, along with controllers and views (well, top level within an `app` directory, as is custom in a Rails project). So you end up in situations where people either have a "Model(record)/Service/Decorator/OtherModelPattern/OtherModelPattern/OtherModelPattern/Controllers/Views" system, a system where all the domain logic is put into ORM classes, or a system where all models are organized within the `models` directory, but possibly interfering with the intuitive file lookup of the framework (eg, if you tried putting all active record models in an `app/models/records` directory and having a huge break from Rails tradition). If Rails simply used "Record" instead of "Models" for the directory name, a lot of this could be a lot clearer, but we're now what, 18 years deep into the muddying of the MVC waters? As much as I'd love to see a return to using MVC properly, I'd rather concentrate on doing more productive things.