But the same 'munging' of business logic and view logic happens in SPAs and related. It's just a fundamental problem with MVC that the lines are difficult to demarcate well no matter how you define your layers.
That and "model" is tricky to define well when we're talking about data backed by a relational database which can (and should be) be sliced in any number of ways. I've yet to see a good relational->UI mapping that works without badly fossilizing everything into a static and undynamic OO "model" inbetween... In fact this is made even worse in SPA-type systems by having an ORM (or similar) and a REST/GraphQL type layer inbetween the view and the DB. Layers and layers of transformation. Each stripping out the richness of the relational model.
It certainly can. In my experience, I've seen this happen to a much lesser extent, though I've not worked on as many SPAs as others of course.
> It's just a fundamental problem with MVC that the lines are difficult to demarcate well no matter how you define your layers.
Yes.
> That and "model" is tricky to define well when we're talking about data backed by a relational database
And that's why I find it nearly useless to even make it a "thing" other than perhaps for n00b coders who've yet to touch SQL or write many of their own classes/modules, or I guess just have enough experience working with data. Thinking in terms of models for data, IMO, can and I think almost always does pigeonhole data into moving and existing in ways it doesn't need to. In many cases, a formal model makes no sense for the data at hand, and if developers only think in terms of models then everything inherits a ton of complexity that may be of no benefit. It's premature optimization hidden as a convention or pattern.
> I've yet to see a good relational->UI mapping that works without badly fossilizing everything into a static and undynamic OO "model" inbetween.
At which there's no point in using strictly OO or a model paradigm. This is what happens when those highly accustomed to OO realize that their conception of OO is unsafe. Keeping data frozen, static, immutable, or whatever is right thing in more cases than is appreciated, but even when devs acutely realize it after the fact, they often resist giving up using models. If some concept of a model is more of a drawback then a benefit, just get rid of them. I don't care what framework or ORM people are using. Any developer can learn to work with data in a functional way that doesn't involve making data act as an ooey gooey object that can morph (and get messed up) and take on a taxonomy that wouldn't otherwise exist in the real world.
> In fact this is made even worse in SPA-type systems by having an ORM (or similar) and a REST/GraphQL type layer inbetween the view and the DB. Layers and layers of transformation. Each stripping out the richness of the relational model.
What about GraphQL that is quite literally just your database structure? IE, verbatim columns and foreign key relationships.
I have this issue too -- you can make an infinite number of onion-ey layers of abstraction over your data. But at the end of the day, there's only one canonical representation of it -- in your data layer.
This is why I am against marshalling naming conventions across programming languages. If your database has snake_case columns, keep the values snake_case when working with them from API responses in your code. If you change the casing, you now have something that doesn't represent what's in your database anymore.
Want data that doesn't exist in a table? Make a view or call a function.
To be fair, I have 0 experience with GraphQL so I probably should not have mentioned it. I spent the last 10 years in pseudo-embedded land and systems programming and some purely backend high throughput systems (ad tech), not doing much 'web' related. I'd like to play with GraphQL.
That said, GraphQL is not a relational query language, and works in the world of hierarchical/graph database land. I think Date & Codd did a good job of critiquing that model and showing its faults the first time around (the 1970s).
> I have this issue too -- you can make an infinite number of onion-ey layers of abstraction over your data. But at the end of the day, there's only one canonical representation of it -- in your data layer.
Right, and the amount of effort spent by devs working within layers of abstraction can outweigh the effort they'd otherwise spend working with pure data, even if other issues arise; said issues would be faster to solve without lots of code in the way.
People forget that an abstraction doesn't make things easier to understand, but this is how many new devs are taught and think about abstraction. Abstractions are only simpler so long as you don't ever need to worry about what that abstraction is doing. As soon as an abstraction is misbehaving mysteriously, inevitably you have to open the hood and see what's up with the engine.
It doesn't even matter if the abstraction was made by really smart people with distinguished titles. At every Rails job I had, there was at least one problem with an abstraction in either ActiveRecord or other things like Rails Engines that were totally inexplicable by anything – they only were solved by hours upon hours of mid-level devs digging through framework code until they came up with a monkeypatch.
Part of this also comes from what I believe is a very misguided desire to leave the door open to switch databases. During my first two Rails jobs, senior developers resisted to use any raw SQL queries anywhere because "what if we switch to Postgres?" Never did that pan out, and in the meantime devs were forced to do weird things with ActiveRecord to make things work, often inefficiently.
I remember when I was momentarily the most senior dev at one of these jobs, once the lead had left, and I decided to just use SQL where it made sense. Not only did this cut down on lines of code and method calls, but those queries ended up being significantly faster, reducing page load time.
Sure, I didn't go through the trouble to force that raw data into an ActiveRecord model, but so what? All we wanted to do was display the data to the user. Why introduce a bunch of ORM gobbledygook for read-only? Because we might want users to edit articles in some hypothetical future where we just let any rando write stories? lol
That codebase was never great, but after some of those kinds of adjustments we somehow didn't get much if any emergency calls after hours anymore. Hmmm...
Abstractions can be great, but I've come to think they rarely have value with persistent data. In a game engine, it can make sense to have model-like objects for things that are ephemeral in gameplay but need to know about one-another, and this is usually easier to implement in a custom way because games usually aren't written like web apps.
> Want data that doesn't exist in a table? Make a view or call a function.
> I remember when I was momentarily the most senior dev at one of these jobs, once the lead had left, and I decided to just use SQL where it made sense. Not only did this cut down on lines of code and method calls, but those queries ended up being significantly faster, reducing page load time.
That's so familiar. I've also been trough this more times than I'd like to admit. Often five or six files of ActiveRecord code that could be reduced to a View.
However I don't think it's just desire to change databases, there's also a lot of resistance against using different languages. SQL is bad, it's ugly, it's old. I see the same sentiment against Bash in younger developers too. They don't want to take the time to learn, so they just reject it.
Bash is bad and ugly… But I just avoided a day’s worth of development of a little command line utility by adding two alias lines that go into .profile.
That and "model" is tricky to define well when we're talking about data backed by a relational database which can (and should be) be sliced in any number of ways. I've yet to see a good relational->UI mapping that works without badly fossilizing everything into a static and undynamic OO "model" inbetween... In fact this is made even worse in SPA-type systems by having an ORM (or similar) and a REST/GraphQL type layer inbetween the view and the DB. Layers and layers of transformation. Each stripping out the richness of the relational model.