MVC reports was originally drafted by Trygve Reenskaug, as on February 12, 2007 . I dont claim any originality of this post. I have just posted the summary and take away of the report. Many Thanks to Trygve Reenskaug for the MVC revolution.
MVC : Model – View – Controller
The paper/report talks about giving users the control over their information as seen from multiple perspectives. MVC architecture is explained as the general solution to the problem of users controlling a large and complex data set.
The initial architecture had four components.
Thing – Something that is interest to the user which can be concrete, abstract, idea, opinion, whole or part. It can be a complex task with large number of interdependent details which can be visualized in many possible ways.
Model – It is a clean representation of the abstract project model. A complex project can be considered as one large model that can be sub divided into number of sub models.Models are collection of data together with the methods necessary to process the data. All models should be consistent.
View – They show one or more pictorial representations of the model on the screen and on hard copy. For example: ListView, TabularView, DiagramView, GanttView, ChartView. There is generally some sort of information required which is not part of the model (scroll, position etc) but generally captured by view.
Editor – is the interface between user and one or more views. Editors are views with necessary coordination and command messages.
The next version had three components: Model, View and Controller. Editor was made part of the controller.
The architecture diagram can be seen below:
Model – Model represent knowledge. It captures the world as perceived by owner. There should be a one-to-one correspondence between the model and its parts on the one hand, and the represented world as perceived by the owner of the model on the other hand. The nodes of the model are identified parts of the problem.
The domain knowledge or the business logic belongs to the model. A model has set of states and a change in state will trigger a notification. Model is attached with views. Models eliminate out the trivialities of the project which the designer need not worry about. Model does not have any information about how the the rendering happens to the user nor how the representation of model happens on screen.
View – Gives the visual presentation of its model. It highlights few and suppress other properties of the system. It gets from model and also update the model. The view should be aware of the terminology of the model.
View interacts with model. It asks model for the required information which has to be used for presentation. It is a presentation iter. It also updates the model by sending appropriate messages. As the view is dependent on model, it will have to adhere to the semantics of the features and properties of the model
Controller – Links between user and system. It provides user with input by arranging for relevant views to present themselves in appropriate places on screen. It provides means for user output by presenting the user with menus or other means. Controller is not meant to never supplement the views. View should never know about user input instead it should always be possible to write a method in controller that sends messages to views which exactly reproduces any sequence of user commands.
Editors are part of controllers. Some views provide a special controller, an editor, that permits the user to modify the information that is presented by the view. Such editors may be spliced into the path between the controller and its view, and will act as an extension of the controller. It should always be possible to write a method in a controller that sends messages to views which exactly reproduce any sequence of user commands.