In this chapter you examined some of the criticisms leveled at Cairngorm. These noted the expense of data binding as the main mechanism for notifying views, the "over-reliance" on singletons, and the fact that Cairngorm projects require a large number of classes to be created even to do something relatively simple.
There is no such thing as a perfect system. All systems have strengths and weaknesses. There is nothing that says you have to use all the parts of Cairngorm or use it at all.
Steven Webster of Adobe Consulting is one of the authors of the six-part article "Developing Flex RIAs with Cairngorm Microarchitecture" (www.adobe.com/devnet/flex/articles/cairngorm_pt1.html). I used his article as one of the sources for this book and it's referenced in numerous articles about learning Flex. Webster also wrote an article titled "Why I Think You Shouldn't Use Cairngorm" (http://weblogs.macromedia.com/swebster/archives/2006/08/why_i_think_you.html). The basic idea expressed in the article is that Cairngorm may or may not be appropriate for your project — this is something you need to determine before deciding to use it. Cairngorm (or any framework) is a tool. Just as using a sledgehammer to put a thumbtack in the wall may not be the best solution, Cairngorm may not be the right solution for your project or problem.
There seems to be some idea in the development world that using a framework or a design pattern makes a person a better developer. I know that when I first ...