Model-Document-Renderer is an evolution of Passive-View design pattern, suggested by Martin Fowler [1]. The difference is mainly in the terminology and in the suggested way of decomposing the application.
In this design pattern a web application is decomposed on Model, Document and Renderer (see Figure 1). It differs from ‘the talk of the town’ MVC (see Figure 2) by the fact that the View (1) degrades to simple renderer, loses (2) control and (3) dependency on the Model and thus becomes (4) application invariant. On the contrary, the Document (5) combines model-depended parts of the View and the Controller, implements (6) application-specific behaviour and (7) control on data flow.
 |
 |
| Figure 1 | Figure 2 |
Model
The Model in MDR is the same as in MVC: it provides application domain objects and implements their persistence.
Document
The Document provides access to a concrete part of the model and implements certain use cases. It is expected to be application-specific and output-format-irrelevant. Also, it should not depend on the container (e.g. application server), leaving these aspects to the Application. Document is responsible for:
- getting proper business objects from the Model
- applying proper template and renderer to the document data
- presenting the rendered view to the user
- capturing user’s action and data entered by the user
- inferring the immediate document state from the data supplied by the user
- updating the model when user selects appropriate action
Application
The Application (not shown on the diagrams) is what actually deployed to and called by the application server. The Application may include several documents, which Application distinguishes by the URI and selects for processing a request. The Application should not directly embed any business logic, model references or rendering functionality. It is responsible for selecting an appropriate document and cross-document navigation.
Renderer
Renderer is responsible for:
- generating appropriate stream of tokens (HTML, XML, CSV, others)
- properly decorating the data (escaping, quoting, etc)
- localizing labels and captions
- formatting the data according to the format patterns, specific for the selected template and/or the currently selected language
A passive template engine is one of possible implementations of the Renderer. A good theory applicable to template engines is given in [2]. It describes motivations for separating code and HTML and rules for strict separation. According to this theory, a template engine should implement four predicates: (1) attribute reference, (2) conditional inclusion, (3) recursive reference and (4) template application.
References
1. Passive View, Martin Fowler
http://www.martinfowler.com/eaaDev/PassiveScreen.html
2. Enforcing Strict Model-View Separation in Template Engines.
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
3. Web Presentation Patterns, Jonathan Snook
http://www.digital-web.com/articles/web_presentation_patterns/
Post a Comment