This was in response to the following:
Originally Posted by Selkirk
I agree with your point that the mere separation of presentation and domain logic is not automatically MVC. Taking the definition from your own artcle:
Originally Posted by dagfinn
To be 'proper MVC' an application must have 3 separate components each of which performs the function of either model, view or controller. It is this level of functional separation, the separation of logic, which is vitally important. The method of communication between these components is largely irrelevant, so the description of the view which "obtains data from the model and presents it to the user" does not mean that the view MUST 'pull' data out of the model itself. It merely says "obtains", which does not close the door to the possibility that the controller may 'pull' the data out of the model then 'push' it to the view.
Originally Posted by http://wact.sourceforge.net/index.php/ModelViewController
If you examine my own implementation of MVC you should notice that I have separate components which can be identified as performing the function of model, view and controller. My implementation may be totally unique, but that should be totally irrelevant.
Scanning down your article I see other properties of MVC which are also contained within my implementation:
Yup, all of those.
- The goal of MVC is to make the model independent of the view and controller which together form the user interface of the application.
- An object may act as the model for more than one MVC triad at a time.
- Since the model must be independent, it cannot refer to either the view or controller portions of the application. They model may not hold direct instance variables that refer to the view or the controller. It passively supplies its services and data to the other layers of the application.
Although not all of my components are classes, my implementation contains the following levels of reusability:
The purpose of MVC is to separate UI from domain logic. In doing so, an MVC implementation typically develops a set of reusable classes for each of the concerns in the triad.
- A domain object (model) can be accessed by any combination of controller and view.
- I have reusable controllers, which means that a controller can be used on any model.
- I have reusable views (in the form of XSL stylesheets) which means that the same view can be used on any model, and it may even be shared amongst several controllers.
This is the only place where my implementation diverges. Due to the passive nature of HTTP my controller tells a model to do something, and when it has done it the model gives its response back to the controller. The controller then takes this response and converts it into an XML document before giving it to the view (an XSL stylesheet) for processing. Thus my views have no communication with any model.
The controller receives and translates input to requests on the model or view.
The controllers are typically responsible for calling methods on the model that change the state of the model. In the passive model (i.e. HTTP), the controller is responsible for telling the view when to update.
In MVC, The controller is NOT a Mediator between the view and the model. The controller does not sit in between the model and the view. Both the controller and the view have equal opportunity to access the model. The controller does not copy data values from the model to the view.
Does the fact that my implementation breaks this one little rule mean that my entire implementation is invalid? Is this rule cast in stone, or is it open to interpretation?
That is interesting as I have some information in my model which identifies for each field what kind of HTML control should be used for that field. This information is added to the XML document as field attributes and then acted upon by the XSL stylesheet. You appear to be telling me that it is acceptable whereas others have been very loud in voicing an opposite opinion. Who is right?
Sometimes, data or behavior that firmly belongs on the user interface side of the division can conveniently be represented using the infrastructure of the model side of the division. Thus objects that would appear at first glance to be in the model are really part of the interface concern, that is the view and controller.