> I find it dubious that a concept of a "model" is even necessary as a thing to always think about; it's a weird implementation detail that's treated as if it's a design pattern.
Are you saying you find it dubious that what you're displaying should be predicated on a well-defined collection of data? Because this is what a model is.
If that's what you're saying, I'm not seeing it. Care to expand on it?
For many, the well-defined collection of data is realized in a relational database. In this case, the challenge is mapping this data onto exact requirements for specific data entry screens or reports.
With complex business rules that cannot be easily implemented via database constraints or triggers, or where the same rule is located on more than one data entry screen, then there is a justified need for an intermediate "model" layer for business logic. However, many applications out there just don't have this complexity. In these cases, having an intermediate model accessible via JSON API may be over engineering. You have to double your mappings. A new feature requires that more code be touched, in different parts of the application. For applications with simple business logic and screens that closely map the database structure, this additional layer may not be worth it.
I guess the question is: What's the alternative to defining models? Just passing around DB cursors directly or maybe pulling the results out of a cursor and storing them in a dynamic collection?
I don't disagree that models are pointless if they're not doing anything other than aping the DB. Why waste your time creating another layer of required translation if it doesn't buy you anything?
With that said, I do think there are some benefits to using statically typed models in languages line C# with larger codebases. It seems like it makes it easier to refactor the application code.
As somebody who loves databases, I think the real issue that folks are meaning to critique isn’t actually using a “model.”
It’s using an ActiveRecord-style ORM (or any ORM) without grokking what lies beneath.
A database layer IS a model. It’s just not a class or an object.
ActiveRecord is a really nice trick when it works … but it can create some really performance-killing side effects.
Ruby’s Datawrapper ORM and its siblings in other languages requires understanding both sides (the object system and RDBMS) but can let you get your class/object semantics to play nicely with your database.
And just passing around database connections and arrays of hashes can get you awfully far.
But, if you want to not think about the database layer, ActiveRecord-style ORMs are a real win for developer ergonomics.
And that’s part of the win of Rails/Django/etc. You can live in a single mental model (classes/objects with references to each other) and ignore the database layer.
Except when you can’t.
One reason (not a criticism) that NoSQL can be such a win is that the semantics are closer to class/object semantics. So you’re not trying to manipulate data with an abstraction that doesn’t quite fit.
But most of our projects aren’t Twitter or FaceBook or Google or anything else functioning at galactic scale.
Are you saying you find it dubious that what you're displaying should be predicated on a well-defined collection of data? Because this is what a model is.
If that's what you're saying, I'm not seeing it. Care to expand on it?