Discussion about domain-orientated folder structures in Phoenix

[peerreynders]

@bulldog_in_the_dream

Rails popularized the MVC architecture — but Rail’s version is in many ways a misreading/reconceptualization of the original proposal [1, 2].

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

Whats a Controller Anyway?

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:

… most GUI libraries and windowing systems combined the view and controller functions in a single widget, making the logical separation into view and controller less useful. Later versions of Smalltalk with operating system widgets chose not to use a separate controller.

Objects and the Web. Alan Knight, Naci Dai (2002)

POSA1 further lists under MVC liabilities:

Intimate connection between view and controller. Controller and view are separate but closely-related components, which hinders their individual reuse. It is unlikely that a view would be used without its controller, or vice-versa, with the exception of read-only views that share a controller that ignores all input.

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)).