ExtJS 4應(yīng)用架構(gòu)設(shè)計

應(yīng)用的可擴展性、可維護性和靈活性取決于應(yīng)用架構(gòu)的質(zhì)量。不幸的是，這往往被視為馬后炮。概念設(shè)計和原型變成了大規(guī)模的應(yīng)用，許多應(yīng)用的基礎(chǔ)基本就是示例 代碼的復(fù)制與粘貼，這很誘人，因為這可以讓你在項目在開始階段有一個快速的進度。 然而，節(jié)省下來的時間相對于項目后期的維護、擴展甚至重構(gòu)應(yīng)用的時間來說，算不得什么。比較好的的方式是寫一個可靠的架構(gòu)，在實施前編寫好遵循的約定和定 義應(yīng)用的視圖、模型、存儲和控制器等。在這篇文章，我們將會看到一個受歡迎的應(yīng)用并討論如何構(gòu)建用戶接口，從而創(chuàng)建可靠的架構(gòu)。
代碼結(jié)構(gòu)
應(yīng)用程序架構(gòu)體系會為實際類和框架大媽提供結(jié)構(gòu)和一致性。建立一個好的架構(gòu)有以下主要好處：
■ 每個應(yīng)用的工作方式是相同的，因而你只需要學(xué)習(xí)一次。
■ 在應(yīng)用之間很容易分享代碼，因為工作方式是相同的。
■ 你可以使用ExtJS的生成工具為你的應(yīng)用程序創(chuàng)建經(jīng)過優(yōu)化的發(fā)布版本。
在ExtJS 4創(chuàng)建你的應(yīng)用時，應(yīng)該考慮一下我們定義的約定，尤其是統(tǒng)一的目錄結(jié)構(gòu)。這個結(jié)構(gòu)要求所有類文件都放到app目錄下，在該目錄下，可根據(jù)命名空間劃建立models、views、controllers和stores等4個子目錄。

雖然ExtJS 4提供了如何構(gòu)建你的應(yīng)用的最佳做法，但是你也可以根據(jù)自己需要修改我們建議的文件和類的命名約定，例如，你可以為你的控制器在“Controller” 前加上前綴，如“Users”修改為“UsersController”。在這種情形下，記得給所有的控制器文件和類加前綴。最重要的一點是，要在開始編 寫應(yīng)用程序前定義好這些約定并遵守它。這樣，你就可以在任何需要的地方調(diào)用這些類。我們強烈建議要遵守控制器、模型、Store、視圖這4個文件夾的命名 約定，這可以確保你可以使用SDK Tools beta對應(yīng)用進行優(yōu)化。
尋找平衡點
視圖
將應(yīng)用程序的UI分割成視圖是好的開始。通常做法是，你提供線框，而設(shè)計師創(chuàng)建UI實體模型。嘗試一下使用以下模型，讓我們的設(shè)計師如何使用ExtJS重建（非常有吸引力）Pandora應(yīng)用。

我們需要在視圖粒度與通用性之間尋求一個平衡。讓我們看看當(dāng)劃分太多視圖的時候會發(fā)生什么。

將UI劃分成太多小的視圖將會讓視圖在控制器中變得難以管理、引用和控制。另外，由于每個視圖都有其自己的文件，創(chuàng)建過多的視圖會讓定義UI塊或視圖邏輯時很難找到視圖文件。
另一方面，我們不希望視圖變得太通用，因為這樣在修改時會失去靈活性。

在這種情況下，每個視圖已經(jīng)過于簡化。當(dāng)視圖的幾個部件需要自定義視圖邏輯的時候，視圖類最終會有太多的負擔(dān)，產(chǎn)生的視圖類變得很難維護。另外，當(dāng)設(shè)計師考慮改變UI時，我們不得不重構(gòu)視圖定義和視圖邏輯，這是相當(dāng)煩人的事。
當(dāng)我們可以輕松的在頁面上重新排列視圖，熱切不需要每次都重構(gòu)它們的時候，說明已經(jīng)取得了平衡。例如，我們可以把廣告作為獨立視圖，這樣，我就可以很容器移動它，甚至刪除它。

在這一版本，我們根據(jù)視圖的任務(wù)來劃分UI。一旦你對使用視圖組合UI有整體思路，那么，你就可以在實現(xiàn)它們時對其粒度作出調(diào)整。有時候，你會覺得兩個視 圖應(yīng)該成為一個，或是視圖太通用，需要將其劃分成多個視圖，這是一個良好的開端的基礎(chǔ)。我相信我們已經(jīng)做到了這一點。
模型
現(xiàn)在我們已經(jīng)有了視圖的基本結(jié)構(gòu)，是時候考慮模型的問題了。通過考察UI中動態(tài)數(shù)據(jù)的類型，我們可以獲得應(yīng)用中所需的不同模型。

我們已經(jīng)決定只使用兩個模型：Song和Station。我們可以定義多兩個模型：Artist和Album。然而，與視圖類似，我們并不想定義模型時也 變得太通用。在當(dāng)前情況下，我們并不需要將artist和album信息獨立出來，因為當(dāng)前應(yīng)用不允許用戶根據(jù)指定的artist選擇song。相反，數(shù) 據(jù)是根據(jù)station組織的，song是重點，而artist和album是song的屬性。這意味著我們不能將song、artist和album結(jié) 合到一個模型。這可以大大簡化應(yīng)用的數(shù)據(jù)邊界。這也能簡化在服務(wù)器端的API，因而我們不需要加載artists和albums。因而，對于這個示例，只 需要2個模型：Song和Station。
Stores
現(xiàn)在我們需要考慮如何在應(yīng)用中使用模型，也就是如何設(shè)計Store的問題。

要搞清楚需要使用那些Store是比較容易的。一個好的策略是先確定頁面上所有需要綁定數(shù)據(jù)的組件。在當(dāng)前情況下，我們需要列出用戶收喜愛 stations，一個顯示近期播放過的歌曲的scroller，一個搜索區(qū)域以顯示搜索結(jié)果。每一個這樣的視圖度需要綁定一個Store。
控制器
有幾種方法可以讓你通過應(yīng)用控制器發(fā)布應(yīng)用的響應(yīng)。讓我們開始考慮當(dāng)前例子需要那些控制器。

這里有2個基本控制器：SongController和StationController。ExtJS 4允許你使用一個控制同時其控制幾個視圖。StationController要處理的事情包括創(chuàng)建新的stations，以及當(dāng)用戶喜愛的 station加載后，將其應(yīng)用到StationList視圖。SongController負責(zé)管理SongInfo視圖和根據(jù)用戶的liking、 disliking、暫停和跳過操作更新RecentSong Store?？刂破骺赏ㄟ^應(yīng)用事件的觸發(fā)和監(jiān)聽實現(xiàn)相互之間的交互。當(dāng)我們可以創(chuàng)建余下的控制器，一個用于管理playback，另外一個用于搜索 stations，我想我們已經(jīng)找到了好的劃分響應(yīng)的方法。
三思而后行
我們分享我們的想法，重點在于希望有助于你寫代碼前的應(yīng)用架構(gòu)的規(guī)劃。我們期望通過應(yīng)用程序的細節(jié)討論有助于你建立更靈活的更容易維護架構(gòu)。