R3 Web Application Pattern

Preface

The most popular pattern for web application development is Mode View Controller. In this pattern, controller processes Request, updates the Model and call View to generate representation. The pattern is pretty simple and powerful, while it has some disadvantages. Take a look for diagram from Wikipedia article:

The solid lines show direct associations, and dashed ones are optional indirect. All three parts of the application are tight coupled: Controller should know Model structure to update values, View depends from the model structure, and once again Controller depends from view; at least for names of input parameters. That’s pure procedural architecture with dumb model. Controller cannot be reused for different models or views, even different request methods require different procedures in the Controller. So, the goal of proposed pattern is to reduce dependencies between parts of application, and use the power of Object Oriented programming languages.

W3C Architecture

From the “Architecture of the World Wide Web”, each  URI identifies one resource. Resource itself associated with some object. When agent request URI for some resource, it gets back Resource representation. A representation is data that encodes information about resource state. As you can see, it doesn’t complete match MVC pattern.

Resolver, Resource, Representation

The proposed Resolver, Resource, Representation pattern ( R3 ) follows W3C architecture and better fit Object Oriented Architecture.

• Resolver processes URI from client request and returns Resource instance associated with request URI ; this is called dereferencing the URI.
• Resource is the programming Object instance, that represent some concept. It contains data fields and methods. Requests that modify resource change its attributes or call methods on Resource Object . Resource can have relations to others. These relations represented as links to URI’s associated with these resources.
• Each resource has one or more Representations, that converts Resource object into web data.
• Additional parts of application include mapping between request data and Resource methods / attributes and Representation controller that decides how to show resource for client.

In this architecture Controller becomes URI Resolver decoupled from the both Model and View internals, dumb Model evolves into rich Resource Object with data and methods. In comparison with MVC, only one tight coupling between Resource and View remains.
It’s also fit full REST architecture recommendations. Instances of application Model objects becomes Web URI’s, relationships between them can be represented as links, and object methods mapped to the request methods and data, and Representations can be selected from content negotiation.
Programming Application flow also can be pretty easy: Resource method can return the next object, that becomes a new application state either for the current request or as redirect to URI associated with new state.

Advertisement