如果我在MXML組件上選擇模塊,我會得到什麼好處?
模塊和組件是兩個非常不同的東西。模塊就像Windows中的DLL或Java中的Jar文件。它包含一段代碼,可以在運行時加載和卸載。所以模塊可以包含一個或多個MXML組件。它們不會取代MXML組件的使用。無論您是否使用模塊,您仍將使用MXML構建您的應用程序。不幸的是,模塊包含許多其他「功能」,而這些「功能」並沒有像Java中的Jar文件那樣簡單。
他們有一個好處和壞處。您可以通過加載和卸載代碼來減少內存佔用,但是現在字節代碼的大小並不是內存膨脹的主要罪魁禍首。實際上,這些語句如何使用導致內存增加的堆。您可以輕鬆地使用SWC在不使用模塊的項目之間共享代碼,也可以通過共享的SVN項目簡單共享代碼。
模塊的其他缺點是它會在程序中創建更多的邊界。從模塊內引用對象可能是一個問題。使用模塊的對象可以引用在模塊中定義的對象,但反之則不然,所以如果您對組織模塊的方式不夠謹慎,則最終可能會將代碼轉儲到不屬於該模塊的模塊中。
我會開始不使用模塊,然後重構,如果我有明確的需要他們。一旦你開始使用它們,模塊只會讓開發開銷的開銷增加。
構建Flex應用程序的最佳方式是什麼?
MVC或MVCS。模型視圖控制器或模型視圖控制器服務。有些人被掛上了命令比控制器好,但是真正的命令是隻有一個控制器方法的控制器。這是一個退化控制器。我喜歡控制器,因爲通過添加一個方法而不是像Commands指令那樣創建一個全新的類,可以很容易地向Controller添加一個新的命令。再加上一個控制器可以讓你將常用的功能組合在一起用於屏幕,子系統等。你可以選擇你希望你的控制器有多好的晶粒。當控制器變得太大時可以很容易地分裂。
MVCS很容易在沒有框架的情況下完成,但使用框架是一個好主意,因爲它可以幫助您的團隊瞭解應用程序如何組合在一起。另外開源軟件在爲你記錄框架方面做得很好,所以你不必回答關於框架的很多低級問題。很好的選擇是Swiz,Parsley或者Mate。但是,大多數人現在正在將Swiz或Parsley轉移到Mate和Caringorm之外。 Caringorm將在未來的FYI中成爲歐芹。
演示模型模式將幫助你,當你想做更多的單元測試,所以看看這些作品將如何有利於你的研究。儘管我更像是一個單元測試Controller和Model,並且爲View或集成測試執行傳統QA。質量保證要容易得多。
由於應用程序將與後端進行通信,我們是否需要使前端更復雜?
您必須對您希望前端處理多少複雜性做出決定。後臺處理是Flex中的一個弱點,所以有時候傳遞給後端是有意義的。我認爲您會對前端的工作量感到驚訝。 Flex是一個RIA,這意味着前端將會發生更多的工作,這是正常的,但你必須決定什麼地方有意義。
我的建議是前端使用JSON或AMF(Blaze DS)在後端調用簡單的服務。如果您需要類似服務器推送的功能,則可以使用ActiveMQ,因爲它具有Flex的連接器。
是否有任何基於模塊的架構用於示例預覽或任何示例,他們已經定義了一個好的架構。
模塊和體系結構互相影響,但使用模塊並不意味着您有一個定義良好的體系結構。您只需將代碼轉儲到代碼塊中。模塊不會在代碼中指定職責或組織,而這正是架構的職責。正如我所說的模塊就像DLL一樣,你沒有看到一個基於DLL的架構,你可以從現成的架構中選擇。像Swiz這樣的框架將有助於定義您的架構而不是模塊。我會說停止關注模塊,看看架構,然後看看你是否需要它們。
還有另一個框架可以使用嗎?它使得生活與太多的框架真正混亂。你能否向我展示任何架構的例子,而沒有實現任何框架。 – Thalaivar 2010-12-02 16:16:39
這也讓我有點瘋狂,用於完成看起來很簡單的任務的框架數量。儘管我同意這篇文章的大部分內容,但這是一個非常具體的項目問題,我認爲還有一件需要考慮的事情是可以在應用程序展開後部署這些模塊,以便在這裏或那裏更新一個功能塊無需重新編譯主應用程序),應該注意的是,要共享的模塊也會失去一些優化,所以swf A + B比包含相同代碼的swf C更大。 – shaunhusain 2011-01-04 02:45:26