我有一個約20個模型和控制器的應用程序，我沒有使用任何特定的框架。 Flex在性能方面使用多個遠程對象的最佳做法是什麼？多個RemoteObjects - 最佳實踐
1）方法1 - 每個元器件 - 每個組件實例化一個RemoteObject本身
2）方法2 - 多個在應用程序根 - 每個控制器由一個RemoteObject在根處理
3）方法3 - 一個在應用程序根目錄 - 將所有控制器爲一類，並用一個RemoteObject的
我猜3將有處理它們最好的表現，但會太混亂，不能保持，1將是最乾淨的，但會造成性能下降。你怎麼看？
最佳做法是「以上都不是」。您的視圖應該派發控制器或命令組件用來調用您的服務的事件，然後在返回數據時更新模型。您的視圖將綁定到數據，然後視圖會自動更新爲新數據。
我的偏好是每個不同類型的數據或檢索的數據類型都有一個服務類 - 這使得可以根據需要根據需要構建可以交換真實服務的模擬服務。實例如果你有一個複雜的服務器設置，一個正在開發皮膚的開發人員會使用這些模擬）。但是，真的，你如何做到這一點是個人喜好的問題。
所以，你在哪裏你的服務生活，使控制器或命令能達到呢？如果您使用Robotlegs或Swiz等依賴注入框架，它將有一個單獨的對象來處理實例化，存儲和返回模型和服務對象的實例（在Robotlegs的情況下，它也會爲您創建Command對象並可以創建名爲Mediators的視圖管理對象）。如果你不使用這些框架之一，那麼你需要「推出自己的」，如果你不注重架構，這可能有點困難。
一件事的人誰不知道如何推出自己的（如誰寫的舊版本凱恩戈姆的人）往往依傍是單身。這些在當今時代並不被認爲是好的做法，特別是如果你對單元測試你的工作感興趣。http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/
在很大程度上取決於你有多少數據，它得到了多少次從服務器刷新，你必須支持更新和查詢。
號3（和圖2）基本上是一個單件 - 其趨向於最適合大型應用程序和大型數據集。是的，維護自己會很複雜，但這就是爲什麼人們傾向於使用框架（puremvc，cairgorm等）。大部分的複雜性都是爲你處理的。在框架中緩存數據還可以提高性能和響應時間。
1的問題是，如果你要協調每個組件的數據更新，你基本上需要寫一個無狀態的UI，總是從每個零部件可見的服務器檢索數據。
編輯：我使用cairgorm - 有30〜域模型（200個左右的遠程調用），還可以使用視圖模型。我的一些模型（遠程對象）具有數千個對象實例（記錄）的10個，我用/寫回緩存。所有的複雜性都封裝在控制器/命令中。性能可以接受。
就純粹的表現而言，所有這三者應該大致相同。您當然會使用更多的內存，因爲有更多的RemoteObject實例，並且有一些額外的字節會與第一個請求一起發送，這些請求是與給定的RemoteObject實例一起發送給您的服務器的（AMF協議的一部分）。但是，這些東西的影響可以忽略不計。因此，艾米是正確的，你應該根據易維護性而不是性能來做出選擇。