客觀地說，Cairngorm優於PureMVC有哪些優缺點？

Question

在Flex中使用MVC框架的原因有很多，但挑選合適的框架似乎很棘手。我對你們從實施這些（或另一個）實踐的經歷中感受到的感興趣。

山姆

Answer 1

The question has already been asked，但是因爲你的cairngorm和puremvc的具體好處明確要求，這是我的想法：

• 兩個puremvc並凱恩戈姆使它很難編寫測試代碼。這主要取決於他們使用全局變量，這些全局變量緊密地將應用程序代碼綁定在一起，這使得很難隔離任何測試部分。 Cairngorm比PureMVC更真實，但都很糟糕。

• PureMVC比Cairngorm更具侵略性（意味着您的代碼嚴重依賴於框架，例如您必須子類/實現框架類/接口），但這並不意味着Cairngorm不是。

• Cairngorm充滿了大量使用全局變量的反模式，PureMVC隱藏了自身最糟糕的部分。

• PureMVC是反Flex，Cairngorm只是不使用Flex的許多好的部分。我的意思是說，PureMVC重塑了Flex已經擁有的許多功能，因爲它想要成爲平臺不可知論者，而且由於其架構，特別是中介，它使得使用綁定實現全部功能變得更加困難。 Cairngorm只是跳過事件冒泡之類的事情，而是選擇涉及全局變量的解決方案。

簡而言之，Cairngorm是Flex的VisualBasic，它的工作原理，但會教會你很多壞習慣。 PureMVC並不是很糟糕，但它不適合編寫Flex應用程序。

我認爲你應該看看的是Mate，它使用Flex來充分發揮它的潛力，它不是圍繞全局變量構建的。相反，它可以幫助您編寫鬆散耦合的，可測試的，可重用的和可維護的代碼，而無需在其他應用程序框架中看到的對框架的沉重和不必要的依賴關係。

如果您由於某種原因不喜歡伴侶，嘗試Swiz，這是在凱恩戈姆有很大的改進，但仍然有使用全局變量中央事件分派一些奇怪的偏好（這是完全離奇考慮的一個框架的要點是避免Cairngorm的惡意全局變量）。