[Diagram updated on 10/27. Thanks to @frozencanuck for his feedback.]
The RIBS diagram is my third attempt to extend the wildly-succesful Model–View–Controller design pattern to encompass first the The DCI Architecture and now the REST architectural style. This time, I started by reverse-engineered the design principles behind the Ki Statechart Framework, particularly their use of statecharts as coordinating controllers.
I also have a clearer picture of what I am doing: trying to identify a general design pattern for computational systems.
Here’s what it looks like so far:
Resource • Interface • Behavior • State
- The purpose of a System is to manage a Resource
- A System contains a Resource, one or more States and their Behaviors, an Interface for each State, plus relationships with zero or more Peers.
- An Interface (which could also be a System of its own) consists of active Actions and passive Presentations available to an external Client.
- When a Client invokes an Action, the System routes it to the appropriate Behavior for the current State (the routing is necessary if there are multiple concurrent states, otherwise it can be elided).
- A Behavior can in general a) adapt a Resource, b) interact with a Peer, and c) initiate additional Behavior
- Resources present to an Interface and adapt to a Behavior
Importantly, this is a conceptual document, not a software architecture. To be sure, it is intended to map easily onto traditional MVC objects:
- Views are Interfaces
- Models are Resources that can adapt and present themselves
- Controllers manage State, routing, and connections with Peers
This implies that traditional MVC concepts are actually aggregates of other, more primitive concepts. Indeed, advanced programmers often add presenters, adapters, routers, state machines, and behavioral strategies in order to overcome the brittleness of pure MVC.
However, the RIBS pattern is actually more general than that, because it applies even below the object level:
- Views can be systems, whose Resource is a drawing context and Behavior is hit detection
- A Model object could itself be a system, with a database row as its Resource and business logic as its Behavior
You might say that one system’s Interface is another system’s Resource. In fact, RIBS can also be used at a much higher level to describe RESTful web services:
- Hypertext is an Interface (HTML) which uses Routes (URLs) to embed State
- Behavior is driven by a small set of Actions (HTTP verbs) against a specific Resource
In short, a RESTful system pulls the State into the Interface enabling you to work directly with Resources.
At least, thats the theory, as best I currently understand it and can articulate it. What do you think? Can you do better?
