To elaborate:
MVC has been subject to re-interpretation over the years - almost to the point of meaninglessness. The web model (Server MVC) goes back to the JSP Model 2 Archtecture (1998) - and really only has a vague resemblance to the pattern outlined in 1979 by Trygve Reenskaug.
MVC: misunderstood for 37 years
MVC past, present and future.
MVC Tree
POSA1 gets into Trygve’s MVC and describes the distribution of responsibilities as :
View:
- Creates and initializes it’s associated controller (***)
- Displays information to the user
- Implements the update procedure (***)
- Retrieves data from the model (***)
Model
- Provides functional core of the application
- Registers dependent views and controllers
- Notifies dependent components about data changes
Controller
- Accepts user inputs as events
- Translates events to service requests for the view
- Implements the update procedure, if required
In Server MVC the View looses a lot of responsibilities (***) - i.e. it is comparatively anemic leading typically to a Page Controller.
Interestingly POSA1 also identifies the Document-View pattern as the result of combining the View and Controller into a single component. And as a matter of fact:
Objects and the Web. Alan Knight, Naci Dai (2002)
POSA1 further lists under MVC liabilities:
Point: in many situations the controller and view are so closely related they may as well be considered belonging to the same component.
Counterpoint: What about an implementation style where most pages are composed of fragment markup rather than all-in-one page markup, most likely because you are reusing “widget skins”? In OO this would be approached with Presentation-Abstraction-Control (PAC)/Hierarchical MVC (HMVC) but in Server MVC you tend to be stuck with controllers that operate at page granularity - which doesn’t match the granularity of your fragment markup.
So depending on the implementation style one can argue both ways - and once again we arrive at the universally dreaded “it depends” (on the details).
As far as I can tell the default organization under (?_web) inside a Phoenix project is favouring making reuse of fragment markup between page controllers as easy as possible (whether or not there are significant opportunities for reuse (or legitimate DRY)).
