1 J2ME應用程序框架的現狀
Sun公司在1999年6月推出了J2ME(Java 2 MicroEdition，Java 2袖珍版)。J2ME是專門為那些使用有限電源、有限網絡連接以及有限圖形用戶界面能力的設備開發的，滿足了消費電子和嵌入式設備開發的需要。
而7年後的今天，消費電子和嵌入式設備發展迅速。硬件設備速度越來越快，存儲容量也越來越大，這也就自然帶動了軟件的發展。MIDP 2.0和CLDC 1.1也相繼問世，各種各樣的JSR也層出不窮。
硬件平台和軟件平台的飛速發展自然帶動了人們需求的增長，也就使得現在的應用程序越來越復雜。以手機游戲為例：以前的手機游戲，一般代碼必須限制在64 KB以內；而現在，大部分手機的這種限制已經取消。上百KB的游戲已很常見，甚至有的J2ME游戲已經超過2 MB。
通常來說，J2ME程序都是比較小的，多數在100 KB以下。而且其中大部分是圖片和聲音，代碼只占其中很少一部分。在J2ME程序比較小時，為了提高程序的執行效率，通常的做法是只用一個類完成整個應用程序，在回調函數commandAction()中完成所有界面切換的工作。例如：
這種模式的好處在於代碼量最小，能得到最小的jar包尺寸，執行起來效率也最高；而且，因為所有界面都在同一個類中，它們可以很方便地共享數據。
但如果界面很多，程序很大，這種模式就體現出它的劣勢了。一方面，幾千行的代碼集中在一個類裡，調試和維護非常不方便。另一方面，由於很多界面都在同一個類中共享數據，使得它們的耦合度大大提高。如果要替換或修改其中某個界面，很可能會影響到其他界面。這就給開發程序帶來了很大的不便。
隨著嵌入式硬件的發展，J2ME軟件的復雜度也越來越大，上述設計模式已不能適應嵌入式發展的需求。這就需要一個更好的設計模式來取代以前的簡單設計模式。下面就介紹一下如何把MVC設計模式應用到J2ME程序設計中。
2 MVC模式的簡介
MVC由Trygve Reenskaug提出，首先被應用在SmallTalk-80環境中，是許多交互和界面系統的構成基礎，Microsoft的MFC基礎類也遵循了MVC的思想。目前這種模式已經非常成熟，並在WEB Application的開發中廣泛使用，apache的開源項目struts就是典型的例子。
MVC的英文全稱是Model-View-Controller，即把一個應用的輸入、處理、輸出流程按照Model、View、Con-troller的方式進行分離。這樣一個應用被分成3個層——模型層、視圖層和控制層。
模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數據，那麼所有其他依賴於這些數據的視圖都應反映出這些變化。因此，無論何時發生了何種數據變化，控制器都會將變化通知所有的視圖，實現顯示的更新。這實際上是一種模型的變化一傳播機制。模型、視圖、控制器三者之間的關系和各自的主要功能如圖1所示。
3 基於MVC模式的J2ME應用程序框架
MVC是一種很好的客戶端軟件設計模式，但目前一般只用於PC上。以JAVA為例，目前已經可以看到MVC大量地應用在J2EE和J2SE上，可是幾乎還很少見到在J2ME上使用MVC模式。這是為什麼呢?有以下兩點原因：
① 大部分的J2ME應用都很簡單，開發周期也很短，很多開發人員偏愛把所有代碼寫在一個類中，認為沒有必要使用復雜的設計模式；
② 使用MVC模式在某種程度上會增大代碼的體積，並且有可能在一定程度上影響程序的執行效率，這在資源相對有限的J2ME系統上是一個不可忽視的問題。
可是隨著嵌入式硬件的發展，移動設備的性能有了很大的提高，從而帶動了應用軟件的發展。J2ME應用軟件變得越來越復雜，如果還像以前那樣使用一個類來完成所有的代碼，必將使得程序可讀性差、擴展性差、可維護性差。然而，如果把MVC模式應用在J2ME應用程序設計中，就可以解決以上的問題。下面列舉並分析幾種在J2ME中比較適合的MVC模式。
3.1 單一控制器的MVC模式
MVC模式是大家都比較熟悉的，整個程序中使用同一個Controller來控制界面的切換和事件的處理等，如圖2所示。
在J2ME應用程序中，界面的切換是比較常見的操作，利用這種單一控制器的MVC模式，可以很容易地實現界面的切換，如圖3所示。
由於界面切換流程都在這個Controller中進行管理，所以程序流程制定得非常清晰。但是由於只有一個控制器，所以如果界面很多、很復雜，就會使得這個控制器十分龐大，影響到開發效率。
3.2 多個控制器的MVC模式
當應用程序界面很多時，可以改變這種情況使用多個控制器的MVC模式，如圖4所示。
在這種模式下，按照程序模塊把界面分成若干個部分，每個部分使用一個控制器來控制。這樣做的好處是程序模塊劃分得很清楚，程序結構更加清晰，也不至於使得一個控制器過於龐大；缺點是程序的類數量更多，控制器之前增加了通信開銷。
3.3 簡化的MV模式
上面的兩種程序設計模式已經很常見於PC上的應用軟件設計，包括WEB應用或J2EE中的設計。但是通常來說，由於基於移動設備的J2ME應用軟件復雜程度相對PC上的要低許多，有時候本來就只有幾個類，如果完全照搬PC上的MVC模式，反而會使程序框架變得更加復雜。這時，可以采用以下的一種變形：MV模式(或稱為MC-V或M-VC模式)，如圖5所示。
在這種模式中，由於去掉了控制器，於是把控制器的功能合並到View或Model中。如果把Controller合並到View中，則可稱其為M-VC模式；如果把Controller合並到Model中，則可稱其為MC-V模式。
3.4 更加簡化的V模式
如果認為上面這種簡化的MV模式還是過於復雜，那麼可以考慮下面的V模式，如圖6所示。
在這種模式中，已經完全省略了Model和Controller，只剩下View了。界面的切換和數據的處理都在各個界面的View中獨立完成。這樣使得類的數量極大地減少，程序執行效率有一定的提高，可是從另一個方面來說，程序的耦合度也增大了。所以，一般來說並不推薦使用這種模式，只有在程序十分簡單、數據量很小時才使用。
4 MVC模式應用在J2ME上的優缺點
MVC模式作為一種已成熟應用在PC客戶端的設計模式，其優點是不言而喻的。這些優點同樣也在J2ME上得到了很好的體現：
① MVC最大的優點就在於它把一個應用分成了3層，這樣程序設計的靈活性就大大增加了。例如，一個應用的業務流程或者業務規則的改變只須改動MVC的模型層，而界面表現方式的改變則只須改動MVC的視圖層。
② 將MVC分離可以讓不同的專家負責不同的模塊。一般情況下，M部分由熟悉數據庫、網絡傳輸的專家負責；V部分則交給對UI有研究的專家。分工意味著可以提高效率並可以按照傳統的責任劃分來處理軟件開發過程，使開發者可以專心於一個領域，從而極大地提高了軟件開發的效率。
③ 模型的部分，因為足夠抽象，可以方便地重復利用，符合OO的思想。另一方面可以利用J2meUnit等單元測試工具對模型進行單元測試，以保證工程質量。
然而MVC模式也存在著一些缺點，而這些缺點在J2ME應用上體現得更加明顯：
① MVC模式應用於J2ME上的最大缺點莫過於增大了代碼體積。據不完全統計，使用了MVC模式後，代碼體積約是不使用MVC的1.5倍。這對PC上的客戶端軟件來說可能不算什麼，可是對於存儲容量十分有限的移動設備則是致命的。
② 模型、視圖與控制器分離，它們之間傳遞數據時會耗費一定的系統時間，這或多或少會降低程序的運行效率。而程序體積的膨脹也使得J2ME在裝載類時會耗費更多的時間，也從一定程度上損害了程序的性能。
③ MVC的3個部件定義並不具體，對於3個部件的具體功能還存在著一些爭議。這給初學者留下不少的陷阱，加大了使用MVC模式的難度。
結 語
綜上所述，當J2ME應用程序比較龐大時，將MVC設計模式應用於程序的框架設計是一個不錯的選擇；而當應用程序比較簡單時，MVC模式的缺點就暴露出來了，這時可以考慮使用MVC的簡化模式——MV模式，甚至是V模式。目前，筆者已將MVC模式應用於J2ME手機播客軟件中，取得了良好的效果。
