tempusfugit (136) [Avatar] Offline
#1
"MVC pattern" is the original 1979 Trygve Reenskaug Smalltalk-79 pattern for desktop application GUIs. Since then the term "MVC" has become an umbrella term for a whole family of patterns and approaches dealing with the propagation of application state, especially after it changes due to external events (including but not limited to the user's own interactions), all the way to the relevant user views for rendering.

MVC: misunderstood for 37 years
MVC past, present, and future
MVC Tree

So given the context of web applications, I think it would make sense to avoid "MVC pattern" altogether and stick to more specific terms such as Server MVC (derivatives of the JSP Model 2 Architecture) and possibly client-side MVC.

Page 3(7)
Over the years, working within MVC’s framework, developers have been able to increase client-side interactivity by using asynchronous web requests.
Doesn't make any sense to me; do you mean:

Over the years developers have been able to increase interactivity of web-based applications by using asynchronous web requests and client-side MVC.

or
Despite the constraints of Server MVC developers were able over the years to increase interactivity of web-based applications by using asynchronous web requests.

(which is what the sentence that follows suggests)


Page 3(7)
A word about business logic
In Figure 1.1 we consolidated the business logic in the controller for simplicity’s sake, but it may also exist in other tiers of the application.
It has always been bad form to include domain-logic in the controller - but certain frameworks elevated that habit to an acceptable practice. The role of the controller has always been somewhat that of a mediator - to transform and route incoming external events to the appropriate capability on the model (or select a transaction script when the necessary actions cross multiple concerns) and to gather and transform data from the model to propagate to the view (when expressed this way it should be clear that the controller always had two responsibilities!** So applying the sensibilities of Command Query Separation to the controller is the first step towards something like flux. Also the model in MVC was never intended to be an inert datastore - the model is supposed to be the "non-visual" portion of the application and therefore the model contains all domain/business-logic (the model could be represented by a collection of services).

See also: What's a controller anyway

Page 3(7)
Consider the validation of a zip code provided by a user
Sound design dictates that it is the service/model's responsibility to validate the ZIP code. Validation of the ZIP in the browser is entirely optional (and should not be relied upon) but is also a reasonable concession to user experience - so while the validation logic in the browser is dictated by the domain, it is strictly speaking not domain-logic (typically nothing in the browser actually is - the "business" of the browser app is to visually represent domain information to the user and to, accept, aggregate and relay user actions to the domain services that actually implement the domain-logic - so the browser app is simply part of the UI to the domain logic, not part of the core domain-logic itself). Validating something like a ZIP code in the database really happens too late and is redundant and wasted effort on top of the validation inside of the domain-logic. It's a measure that is typically taken in integration databases which have been considered an anti-pattern even pre-2004.

**Correction: Seems exposure to the many misquotations of MVC "undid" my understanding of the controller - in the original Trygve Reenskaug pattern the view actually has the responsibility of retrieving the data from the model. According to POSA1:

View Responsibilities
  • Creates and initializes it's associated controller
  • Displays information to the user
  • Implements the update procedure
  • Retrieves data from the model

  • Model Responsibilities
  • Provides functional core of the application
  • Registers dependent views and controllers
  • Notifies dependent components about data changes

  • Controller Responsibilities
  • Accepts user inputs as events
  • Translates events to service requests for the view
  • Implements the update procedure, if required

  • The curious thing is that almost every version of Smalltalk didn't actually separate the view and the controller.

    It's the Page Controller that is sometimes tasked with the transformation of the data that comes from the model to something the Template View can accept.
    Erik Hanchett (34) [Avatar] Offline
    #2
    Thanks for the suggestions! I'll take a look back at the description of MVC and see if we can tighten it up a bit.