User:Damianham/Model View Role

Model-View-Role (MVR) is an architectural pattern used in software engineering. The pattern isolates business logic from input and presentation, permitting independent development, testing and maintenance of each. It is similar to the Model-View-Controller (MVC) pattern but may be more similar to the naked objects pattern.

Model
It is a thing to be acted upon by the application. It includes the domain-specific representation of the data on which the application operates and a set of operations to act upon the data.

Many applications use a persistent storage mechanism (such as a database) to store data. MVR does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects although in very simple apps, with little domain logic, there is no real distinction to be made. Also, the ActiveRecord is an accepted design pattern which merges domain logic and data access code - a model which knows how to persist itself.

View
Renders the model(s) into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A View may be rendered by a Model or by a Role.

Role
It is an actor that acts upon and co-ordinates interaction between different Model types.

Comparison with MVC pattern
With the MVC pattern there is a direct link between the Model, View and Controller. The Controller receives input and initiates a response by making calls on model objects and dispatches to a View to render the result. The business logic tends to be in the Controller rather than the Model. Controllers will often touch different Model types.

With MVR there is no direct link between the Model, View and Role. The business logic related to a model is encapsulated in the model making for a fat model architecture. Either a Model or a Role can receive input and initiate a response by making calls on model objects and dispatching to a View to render the result. A Role object will be used in the cases where the business logic needs to co-ordinate the interaction between different models. It is up to the developer to choose whether a Model or Role object handles the request. If only a single Model type will be touched by the request then the request should be handled by the Model, otherwise it should be handled by a Role object.

Implementations of MVR as web-based frameworks

 * Ruby On Track- A web application framework aimed at deploying Ruby web applications into a J2EE application server.