As I’ve previously mentioned, we’re in the early architecting stages of a Flex application and we’re being confronted with some key decisions to be made. I think some these might be useful so I’ll continue my Flex based posts during the project.
The basic premise of Cairngorm and the ModelLocator pattern is that each Command (responsible for retrieving data from the server via the ServiceLocator pattern) retrieves the data and then updates the Model with the new data. In turn, your Views can then respond to changes in the Model via Flex’s baked-in data binding. This is one of the most useful features of Cairngorm and makes it perfect for large scale Flex applications.
But what about the times when you don’t want the Command to change the Model? One of the downsides of the ModelLocator pattern is if you go sticking everything in the model, it will quickly become polluted.
There has been much discussion in the past about how to best deal with this situation:
- Alex Uhlmann’s post How Business Logic Can Manage Views
- Derrick Grigg’s post Cairngorm, Commands, Views and Harikiri
- Thomas Burleson’s Cairngorm View Notifications
This time around we chose Thomas Burleson’s View Notifications resolution. It seemed to make perfect sense, it was clean and easy to achieve.
After successfully implementing it (which really was simple), I can definitely recommend View Notifications as a means to respond to Commands directly within your Views!
Filed under: cairngorm, flash platform, flex
