Saturday, 10 April 2010

Command and Binding

In this blog entry, I am returning to a programming architecture issue. In this case, I am looking at the use of command chains where the purpose of the chain is to ensure that the data retrieved by the previous command has been stored prior to initiating the next command.

Commands in software are designed to carry out an action that updates the data model. In the rich internet applications (RIAs) that I have worked on, these often involve initiating a call to the server to retrieve data.

Command chaining isn't the solution when one command updates data that should be a parameter to another following command. In such cases the following command has to fetch the value or the command has to be built and called once the first command has finished. In effect, the next command should be initiated when the data has been updated. In Pure MVC, you can use notifications at the end of commands for this purpose. Cairngorm doesn't seem to provide any generic notification mechanism but why should it when there are Flex events and data binding.

The application sequence being implemented is:

  1. load categories
  2. load current user
  3. set current category from user data
  4. load data for current category

The last two steps are clearly dependant on a previous data retrieved. They are a chain that should happen in that sequence with the starting point dependent on the data changes. Reload categories isn't expected to occur but if they did then it may not be necessary to reload the current user but the remainder may be needed just to re-link objects correctly. If the user changes then there is always the need to reset the current category and retrieve the category dependent data.

Many of the chains of commands that are used in applications are data dependency chains. They usually involve a reacting to a change in the data that impacts what is displayed or changes behaviour. If there is a time delay as occurs when data is retrieved from a remote server, then the update of the displayed data or the behaviour has to occur once the new data has arrived. It isn't possible to assume what data will be retrieved or the nature of the change that will occur.

Data binding achieves this type of update for displayed data and could act as the mechanism for triggering a change in behaviour or the next action. For this to work, there needs to be a place where these links can be defined and managed. A data binding can not be linked directly to a command. This is also true for notifications. With data binding in ActionScript, a setter type function is called to initiate the next action.

My proposed solution is to have an application controller in which these setter functions are defined. The data binder watchers would also be defined and initiated here. In effect, the application controller becomes the configuration point for the system. In some respects, this becomes a fa├žade defining the actions of the system and the interactions of the system. Views would interface with the application controller to achieve their task. In effect, this is the system controller.

The configuration of the system would be something like:

This still follows the pattern of MVC or MVP where the view is self-updating based on changes in the data. The explicit flow of control is always through commands to update the model. The data bindings act as the notifications both to the view and to the controller of any actions that should take place as a result of data changes.

The alternative is that setters in the model cause follow on actions but that has the same effect as using data binding. Causing follow on actions from the setters also increases the coupling in the system making it more difficult to reconfigure.

No comments: