it's worth reading some of the early smalltalk/MVC stuff to try to understand how MVC was originally formulated (http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerP...). it can be a little hard to understand, because it's pretty significantly different from how most modern GUI toolkits work, but (as i understand it, not actually having written smalltalk code) at its core it's fairly simple:
Model: business data
View: on-screen representation of Model; reacts to changes in Model to re-draw accordingly
Controller: maps user input to changes in Model; may need to interact with Views, and may pass control through a hierarchy of Controllers, to determine the Model being manipulated
in other words, user-input data flows as: C -> M, and M -> V. i see a Controller modifying a View (rather than just querying it) as impure MVC, and i normally strive to avoid it, even though that's essentially impossible if you're forced to use a platform's GUI toolkit.
i don't think of MVC as having "gone wrong," but rather that the name has been co-opted and the pattern corrupted by so many different people, in many different ways, as to make the original name extremely confusing. iOS' concept of "MVC" drives me crazy. i think it's probably fair to call it MVP (Model-View-Presenter), the difference being that the Presenter can indeed do some of the work of modifying the View. but i still mostly think of this as a hack: the more work that gets shoved into the Presenter, the more complicated it gets.
If you look closely in the original smalltalk definitions you'll also see that separation of view and controller was intended first and foremost as a way to swap multiple views for the same controller, assuming those views shared controls and interaction patterns. This may have made sense in the context it was designed in : rendering was closer to raw painting on a canvas, mixing event handling with painting code would probably have been ugly. In my opinion it makes much less sense in a browser where the rendering layer is almost entirely in the runtime and building UIs is pretty trivial. We all feel something is wrong because, well, something very is wrong with MVC in the client. Where to we "render" ? To the DOM. Where do user interactions come from ? From the DOM, through events. We already have the controller-view part, and it's the DOM. Everything we are doing, stated or not, is adding layers on top of it to make things simpler to manage. Glorified helpers.
Same goes for the model. If you don't like to duplicate information for the sake of it, it's pretty straightforward to note that models on the client should be ... well, are a glorified caching mechanism. All these MV* models are in my opinion strongly hindering creativity and progress.
In this respect, I think React is onto something big.
It's very interesting to see younger programmers speaking up these days. (No condescension intended; it just feels weird to be entering that old guy stage now, with 15 years of hardcore web/mobile application development experience) These younger guys are very, very sharp with enormous amounts of very cutting edge knowledge about current and quite advanced technologies. No doubt from the enhanced participation/availability model of example code the internet has undergone in the past 6-8 years (really since its inception, maybe it is just wider used now).
I think the keys to MVC for me are the logical silos by type. I don’t remember who first used the term ‘tier’ in this context, but I remember it back in 2000, possibly sooner with RUP to describe a multitier/n-tier application. This was a time of great debate online about the separation of concerns like data and security contracts of the newly developing web services… It had been mostly Cobra, DCOM and EJB’s up until this point. But I digress…
A very basic N-Tier architecture could be looked at like this:
Data Tier: This was the area that the core data logic and rules around the ___domain specific knowledge were guarded--and different from all aspects of the system. Like a phone company and their telephone number, as well as the number of minutes a particular telephone number is allowed, have specific requirements. The Data Model is where those types of requirements and rules are implemented.
Business Tier: Things like a father setting up time walled minutes on his daughter's phone so she can't talk on the phone at night... The data model would not allow even the business logic to set a negative number on the minutes; it would allow configuration of those ___domain model fields within proper bounds.
Presentation Tier: To make it easier on the user, we'll make the data entry screen telephone field on our external application format the input number to our specific carrier’s style: xxx-xxx-xxxx. The Business logic would handle events raised by the presentation tier and return a success message or possibly a failure message triggered from the business silo where the father hasn't paid his bill so the family management aspect of the program will not work until he does. Today, this will most probably be a JavaScript app responding to an asynchronous message from an open source web socket server, but it used to be good old request/response.
There’s all manner of debate as to missing tiers, level of complexity per tier or any manner of versions of good architecture. I've heard the database referred to as the Data Tier, when it was obvious the ___domain model rules require far more granularity and limitations than a simple database could provide.
However, from the above tiers, I think you can see where a M C V architecture begins to emerge from this separation of logic by the type of requirement it falls under. Why it’s ordered: MVC always boggled me—but I’m sure Fowler (aka Captain Obvious) could give us a reason.
The idea did not develop, IMO, from a need to over complicate a simple task, but rather from the large scale factory production mentality of early software shops. If you have the money for 20 developers for a very large project how can you separate their tasks by skill or experience so all their work will be countable like beans? Large engineering processes and tiered architectures, Business Analysts and Data Analysts, and even Architects and Silver tongued CEOs.
This was one of the uses of the whole front-end v/s back-end developer. I think this was a P.C. way of asking if you were an over glorified graphic designer with scripting skills or tier-minded.
Object oriented programming became appealing to some because with highly decoupled separation of concerns and fewer logical endpoints, abstractions could be applied. Every ‘Controller’ could extend an abstract class which could bake in the functionality to log all requests and responses for auditing purposes. You could abstract the data tier so its server load could be managed independently. You could even abstract the logic of the business rules into a new language which could be the savior or large enterprise wide service deployments: BPEL and ESBs.
Let me wrap up: In my opinion: MVC or MV* is a school of thought that has good use when one thinks in the context of the logical grouping of functionality by requirements and their type, with the ability to extend those types individually with functionality across their tier.
Model: business data
View: on-screen representation of Model; reacts to changes in Model to re-draw accordingly
Controller: maps user input to changes in Model; may need to interact with Views, and may pass control through a hierarchy of Controllers, to determine the Model being manipulated
in other words, user-input data flows as: C -> M, and M -> V. i see a Controller modifying a View (rather than just querying it) as impure MVC, and i normally strive to avoid it, even though that's essentially impossible if you're forced to use a platform's GUI toolkit.
i don't think of MVC as having "gone wrong," but rather that the name has been co-opted and the pattern corrupted by so many different people, in many different ways, as to make the original name extremely confusing. iOS' concept of "MVC" drives me crazy. i think it's probably fair to call it MVP (Model-View-Presenter), the difference being that the Presenter can indeed do some of the work of modifying the View. but i still mostly think of this as a hack: the more work that gets shoved into the Presenter, the more complicated it gets.