首先簡單介紹一下Cairngorm框架。大家都知道，Cairngorm是一個廣爲人知的老牌Flex框架。它是一個微型架構——由一些設計模式組成用來降低團隊協作的困難。
Cairngorm從Java的世界帶來了很多開發理念，並且把重點放在三個關鍵區域：處理用戶動作，封裝服務端的交互和業務邏輯，管理客戶端的狀態和界面呈現。
使用Cairngorm來構建一個項目，需要將應用代碼分離到不同的包並且繼承Cairngorm的類。以下是Cairngorm項目中一些主要的部分和類。
Cairngorm是一個廣爲人知的老牌Flex框架，現在我們簡單介紹一下它的優缺點，對於大家掌握系統的知識和軟件學習的選擇具有很大幫助。
ModelLocator是一個儲存數據的單例，數據表示程序的狀態。單例類的性質保證了程序中的所有組件取得的是相同的數據。
ServiceLocator是另一個單例，它集中管理所有服務如HTTPServices。同樣，由於是單例，程序中的所有組件取得的是相同的服務。
業務邏輯被封裝在command類中。command實現了命令模式，它們表示相應用戶事件的邏輯。
事件被類FrontController處理，FrontController會把事件映射到相應的Command。
Delegate類作爲代理來對遠端服務進行請求和響應。
優點
Cairngorm在Flex社區廣爲人知，作爲Adobe開源項目的一員，擁有活躍的社區和開發者的支持。
其次，該框架吸取了Java開發中許多寶貴的經驗，併成功得用於大型項目的開發中。
並且，Cairngorm適用於團隊開發，因爲它提供了結構化的開發方法來創建應用，利於分佈式的開發。
其次,Cairngorm實現了自己的一套事件處理的方法。這增加了Flex內置事件模型的複雜度，而且它還有限制。由於每個事件都有自己的的command，事件的響應者被限制成1個。加之Cairngorm的事件不具冒泡特性，如果要發送數據到容器的其它層次則需要自己來實現。
第三個常見的批評是Cairngorm依賴全局的單例，這讓模塊和單元測試變得困難。儘管可以打破單例中的模型簡化測試，但是會增加額外的過程。
缺點
需要寫大量的類應該是Cairngorm最多的負面評論了。在Cairngorm中，每一個event對應一個command；因此，需要對程序觸發的每一個事件來寫一個command類。而且，還要爲command寫一些其他的類，例如delegates。即使是一箇中型的應用也會導致大量的類產生。