Agreed on the OSI model 🙂

It’s probably best to think of model-view-controller (MVC) as a sort of parent concept for any kind of software application that has a user interface (UI). That’s especially true for a graphical one requiring the transformation of data into a visual representation (as opposed to outputting raw data).

Whether or not it strictly follows the definition of ‘separation of concerns’, it is ultimately concerned with separating parts of the application into one of those three categories.

But the categories could have sub categories, just as there might be core data models as well as “overlay” models that unify them into a sort of meta-model.

Nice to see MVC still getting some press. For seperation of concerns the correct nerd term would be the OSI model where the concept of these layers came from, I believe? Would’ve been nice to see some SOA as well … I don’t agree with models performing business/application functions however. I see the model as purely a Holder layer and view model MVVM as a still relevant hybrid option for binding and transport to the view. But I typically follow a service layer ie: business logic processing tier, where the ugly code goes, which typically has access to the models and data access layer. And keep request responses and sessions,if required, in the controller tier which only takes data or requests in and passes them to services for responses. Totally agree it is just a pattern as well… But also the reason we now have specializations in front end back end and full stack…. As with greater separation comes a greater complexity ramp and it kills me that to this day tthere is still no industry standard across the board on the best way to deliver data with interactivity to any client through a network that can also exist and function offline. In search of the golden template….

The focus of the article is the practical use of MVC in backend web applications. The MVC has many use-cases and implementations and my article goes in depth in one of them.