I've been living for over 10 years in an industry that has espoused the importance of "MVC" for and I still don't really know what it means.

The original article was kind of confusing on this matter--though that could be a result of me reading it right after I woke up (morning ritual: read HN for half an hour, then get out of bed). I find the Wikipedia page easier to understand [0].

And realize now that whatever I've always been doing and whatever I've seen done on all projects I've been involved on has strictly been MVP, not MVC.

I find these statements to be at odds with each other:

> The model directly manages the data, logic and rules of the application

And then shortly after:

> Whenever there is a change to the data [the model] is updated by the controller.

I know every project I've worked on has interpreted that last statement to mean the model is dumb, that the model does not do anything of its own to manipulate data. Of course, that flies in the face of how they have all ended up getting implemented: relational databases with a significant number of stored procedures.

When you're dealing with RDBMSes, there is a big struggle at play between correctness and performance. And there are no strict answers, everything is dependent on the particular situation. You have to profile everything, because it's nearly impossible to predict how anything will perform before trying it. And it can be a big deal, the difference between sub-second processing in one way and over-a-day the other way. It can be ludicrously bad, so you are guaranteed to be compromising "correctness" at several points in time.

One way I've seen that happen is with a heavy use of stored procedures plus "logic layers". There are stored procedures for getting the data out of the database, but then there is a lot more application-level logic for further manipulating the data into its final form. But often--especially any data manipulation that has no linear dependence between records--the most performant solution is to implement the entire logic in a stored procedure. And that would mean that the store procedures the real controller.

But god daaaaammit, every procedure SQL extension in existence right now is complete garbage as an application language.

The more I think about it, the more I suspect MVC is meant to have the controller have only a notional understanding that "data must change", sending the minimum data necessary to the model to make that change happen, but have the model fully implement that change on its own. This is the opposite of the projects from my past: instead of a "dumb" model, it's a "dumb" controller.

But SQL is far too dynamic for my tastes. I want static checking. I want to be able to test at least the validity of the logic (i.e. "yes, a column named 'Something' really does exist. No, there is no 'Soemthing' column. Yes, you can those two columns together and expect an integer out of the deal.") before ever having to even setup a database server and running it.

What I really want is a strictly-typed language with first-class support for set and relational operations that can be used to validate the query logic before transpiling down to platform-specific SQL. LINQ to SQL was supposed to be that, but in the end I think it missed the boat on a lot of static checking opportunities. Entity Framework is supposed to be that, but it runs on SQL Server only [1], the performance can be bad, and the overall design and workflow seem very inflexible. There are other systems that are mostly built on C#'s `dynamic` keyword. And they all are built under the guise of hiding SQL away from the developer, thus wedging themselves firmly into object-relation impedance mismatch problem.

[0] https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...

[1] There are hacks to get EF working on other databases, but they are a pain and it isn't first-class.