DCI
From APIDesign
Data/Context/Interactions - a modernized version of MVC. Originally described at artima article. Here is mine and Geertjan's screencast explaining why DCI is important for development of modular applications and how to realize DCI via Lookup:
DCI separates a program into different perspectives where each perspective focuses on certain system properties. Code in the Data perspective specifies the representation of stand-alone objects. Code in the Context perspective specifies runtime networks of interconnected objects. Code in the Interaction perspective specifies how the networked objects collaborate to achieve the system behavior[1].
Contents |
Emotionally Attached to Model
The base difference mentioned in the screencast is that in MVC only the model is independent on the rest. The view, controller or presenter are always assumed to know what the model is and operate directly on it.
This is not true in DCI. The interactions are written without knowing the actual data. They are general and need to be turned into concrete ones by establishing proper context before they can be performed, executed.
Swing Mental Shift
I do remember arguing for ages with an experienced Swing designer that the (swing) actions are wrong and cannot be used in NetBeans. I was explaining it all, describing that action by itself cannot do much, that it needs some context and that nothing else can work in modular world. No chance, my message just could not pass the gap between modular and monolithic Swing mindset.
Now I know why! The Swing designer was imprisoned in the MVC mental model. For him a component/window represented the model and action was there to act on that model. In NetBeans this is different - the action is just an interaction. It does not do much by itself, it needs properly filled context to enable itself and invoke some operation. The context is then morphed by any window/component that wishes to be recognized by the interaction. It needs to morphs its data into appropriate context.
Quite easy if you have good theory to backup your reasoning with, isn't it?
Yet Another Layer
In some sense the DCI brings another level of indirection ("all problems in computer science can be solved by another level of indirection", can't they?). The interactions know only what context they need, not the real data - e.g. model. In the classical MVC terms the CI is itself an MVC and there is a bridge morphing the D to the new M. This may not seem like a really big change and indeed, technically, it is not. However the mental shift is huge!
Dependency Injection
Is in DCI still a for dependency injection? That is question asked by Andreas in the discussion section. I am not sure whether I am the most qualified person to answer the question, but certainly I have some opinion.
For me the DCI is design paradigm. A general method to help us look, perceive, understand and solve problems we face when converting real world problems into computer understandable language. When using DCI one needs to choose some technology that supports binding of data through some context into the interactions. It can be dependency injection. It can be traits in Scala. It can be Lookup as in the example of action system in NetBeans.
What is the design model behind dependency injection? MVC? Hardly. Where is the model, view, controller? It is much easier to explain dependency injection in terms of DCI - there is some interaction class with setters and the injection needs to feed it up with proper context and data before it can be usable.
So DCI is a general concept and dependency injection is possible one way to realize it.
<comments/>
Follow
