Every application is processing data. It is inevitable that data is structured well. In functional programming you pass data (or handles) from one function to another. In object-oriented programming data is owned from classes and we provide interfaces to read or manipulate it. In all cases you have a model, even when its not declared or explicitly implemented. In the worst-case you model is implicit and distributed over your application. This will make it difficult, if not impossible, to handle the data in an optimal way.
Model driven architectures organizes the modules into a pipeline (see pipeline design pattern). The data is encapsulated and organized into a module or class. Manipulations (removing, changing or adding) will be done on top of this model, via a proxy or decorator model. If you want persistency of course, you can also modify the original. But in case you need only filtering or ordering you don’t want to change the original. Also if you want to revert changes or are only interested in the results a proxy or decorator will do the job. For instance, you can have a filter proxy, an ordering proxy or manipulating proxy, where the returned data is processed.
Most of the time this pipeline ends with an output. You can write it to a file or use it to generate and display user interface controls.
To support such operations, you need to define a well thought API. It depends on the purpose of the application, but you can narrow it down to following properties:
- A structure that will encapsulate an entry
- A method to retrieve one entry
- Changed events are emitted when entries are added, removed or modified
By providing this interface you can define classes, that implement this API and decorate or proxy another implementation (see decorator pattern) . Every time data is changed this change event will be propagated to the decorator and the data will be modified according the decorator’s implementation.
With this architecture its possible to structure your model like an onion, where each layer will add complexity.
This architecture is not only beneficial, when we talk about big data, even on UI development it’s a valuable tool. You can create generic models and generic user interface controls. These controls will adapt its content and behavior according the model. For instance, a List-Control, that will add and remove entries automatically when the model will be changed.
We utilize this approach in our MVC module of our HAN Lib. It will be used for user interface controls, but also for loading and changing assets. Especially our dynamic asset load system will benefit from a model driven architecture. Assets can be automatically loaded on demand and unloaded on the fly. One simple example to end this post:
- SQL Database Model (Table: Unit) -> Unit Model -> Dynamic Resource Loader -> Game
- SQL Database Model (Table: Unit) -> Unit Model -> UI Item Model -> List Control