基于MVC模式的J2ME應(yīng)用程序框架設(shè)計(jì)

　　摘要 隨著嵌入式硬件和軟件技術(shù)的發(fā)展，J2ME應(yīng)用程序的復(fù)雜度和代碼量越來越大，這使得傳統(tǒng)的單一類設(shè)計(jì)模式和框架結(jié)構(gòu)已不能適應(yīng)需求。本文提出了一種基于Model-View-Controller(MVC)模式的J2ME應(yīng)用程序框架的設(shè)計(jì)方法，使得程序更清晰，維護(hù)更方便，極大地提高了開發(fā)的效率。本文首先介紹了MVC模式的概念;接著提出幾種MVC在J2ME應(yīng)用程序上的設(shè)計(jì)模式，并分析了各自的特點(diǎn);最后總結(jié)了這種設(shè)計(jì)模式的優(yōu)缺點(diǎn)。

　　關(guān)鍵詞 J2ME MVC應(yīng)用程序框架

　　1 J2ME應(yīng)用程序框架的現(xiàn)狀

　　Sun公司在1999年6月推出了J2ME(Java 2 Micro Edition，Java 2袖珍版)。J2ME是專門為那些使用有限電源、有限網(wǎng)絡(luò)連接以及有限圖形用戶界面能力的設(shè)備開發(fā)的，滿足了消費(fèi)電子和嵌入式設(shè)備開發(fā)的需要。

　　而7年后的今天，消費(fèi)電子和嵌入式設(shè)備發(fā)展迅速。硬件設(shè)備速度越來越快，存儲容量也越來越大，這也就自然帶動了軟件的發(fā)展。MIDP 2，O和CLDC l.1也相繼問世，各種各樣的JSR也層出不窮。

　　硬件平臺和軟件平臺的飛速發(fā)展自然帶動了人們需求的增長，也就使得現(xiàn)在的應(yīng)用程序越來越復(fù)雜。以手機(jī)游戲?yàn)槔阂郧暗氖謾C(jī)游戲，一般代碼必須限制在64 KB以內(nèi);而現(xiàn)在，大部分手機(jī)的這種限制已經(jīng)取消。上百KB的游戲已很常見，甚至有的J2ME游戲已經(jīng)超過2 MB。

　　通常來說，J2ME程序都是比較小的，多數(shù)在100 KB以下。而且其中大部分是圖片和聲音，代碼只占其中很少一部分。在J2ME程序比較小時(shí)，為了提高程序的執(zhí)行效率，通常的做法是其用一個(gè)類完成整個(gè)應(yīng)用程序，在回調(diào)函數(shù)commandAction()中完成所有界面切換的工作。

　　例如：

　　這種模式的好處在于代碼量最小，能得到最小的jar包尺寸，執(zhí)行起來效率也最高;而且，因?yàn)樗薪缍荚谕粋€(gè)類中，它們可以很方便地共享數(shù)據(jù)。

　　但如果界面很多，程序很大，這種模式就體現(xiàn)出它的劣勢了。一方面，幾千行的代碼集中在一個(gè)類里，調(diào)試和維護(hù)非常不方便。另一方面，由于很多界面都在同一個(gè)類中共享數(shù)據(jù)，使得它們的耦合度大大提高。如果要替換或修改其中某個(gè)界面，很可能會影響到其他界面。這就給開發(fā)程序帶來了很大的不便。

　　隨著嵌入式硬件的發(fā)展，J2ME軟件的復(fù)雜度也越來越大，上述設(shè)計(jì)模式已不能適應(yīng)嵌入式發(fā)展的需求。這就需要一個(gè)更好的設(shè)計(jì)模式來取代以前的簡單設(shè)計(jì)模式。下面就介紹一下如何把MVC設(shè)計(jì)模式應(yīng)用到J2ME程序設(shè)計(jì)中。

　　2 MVC模式的簡介

　　MVC由Trygve Rcenskaug提出，首先被應(yīng)用在SmallTalk-80環(huán)境中，是許多交互和界面系統(tǒng)的構(gòu)成基礎(chǔ)，Microsoft的MFC基礎(chǔ)類也遵循了MVC的思想。目前這種模式已經(jīng)非常成熟，并在WEB Application的開發(fā)中廣泛使用，apache的開源項(xiàng)目struts就是典型的例子。

　　MVC的英文全稱是Model_View-Controller，即把一個(gè)應(yīng)用的輸入、處理、輸出流程按照Model、View、Con-troller的方式進(jìn)行分離。這樣一個(gè)應(yīng)用被分成3個(gè)層——模型層、視圖層和控制層。

　　模型、視圖與控制器的分離，使得一個(gè)模型可以具有多個(gè)顯示視圖。如果用戶通過某個(gè)視圖的控制器改變了模型的數(shù)據(jù)，那么所有其他依賴于這些數(shù)據(jù)的視圖都應(yīng)反映出這些變化。因此，無論何時(shí)發(fā)生了何種數(shù)據(jù)變化，控制器都會將變化通知所有的視圖，實(shí)現(xiàn)顯示的更新。這實(shí)際上是一種模型的變化一傳播機(jī)制。模型、視圖、控制器三者之間的關(guān)系和各自的主要功能如圖1所示。

　　3 基于MVC模式的J2ME應(yīng)用程序框架

　　MVC是一種很好的客戶端軟件設(shè)計(jì)模式，但目前一般只用于PC上。以JAVA為例，目前已經(jīng)可以看到MVC大量地應(yīng)用在J2EE和J2SE上，可是幾乎還很少見到在J2ME上使用MVC模式。這是為什么呢?有以下兩點(diǎn)原因：

　?、偬糠值腏2ME應(yīng)用都很簡單，開發(fā)周期也很短，很多開發(fā)人員偏愛把所有代碼寫在一個(gè)類中，認(rèn)為沒有必要使用復(fù)雜的設(shè)計(jì)模式;

　?、谑褂肕VC模式在某種程度上會增大代碼的體積，并且有可能在一定程度上影響程序的執(zhí)行效率，這在資源相對有限的J2ME系統(tǒng)上是一個(gè)不可忽視的問題。

　　可是隨著嵌入式硬件的發(fā)展，移動設(shè)備的性能有了很大的提高，從而帶動了應(yīng)用軟件的發(fā)展。J2ME應(yīng)用軟件變得越來越復(fù)雜，如果還像以前那樣使用一個(gè)類來完成所有的代碼，必將使得程序可讀性差、擴(kuò)展性差、可維護(hù)性差。然而，如果把MVC模式應(yīng)用在J2ME應(yīng)用程序設(shè)計(jì)中，就可以解決以上的問題。下面列舉并分析幾種在J2ME中比較適合的MVC模式。

　　3.1 單一控制器的MVC模式

　　MVC模式是大家都比較熟悉的，整個(gè)程序中使用同一個(gè)Controller來控制界面的切換和事件的處理等，如圖2所示。在J2ME應(yīng)用程序中，界面的切換是比較常見的操作，利用這種單一控制器的MVC模式，可以很容易地實(shí)現(xiàn)界面的切換，如圖3所示。

　　由于界面切換流程都在這個(gè)Controller中進(jìn)行管理，所以程序流程制定得非常清晰。但是由于只有一個(gè)控制器，所以如果界面很多、很復(fù)雜，就會使得這個(gè)控制器十分龐大，影響到開發(fā)效率。

　　3.2 多個(gè)控制器的MVC模式

　　當(dāng)應(yīng)用程序界面很多時(shí)，可以改變這種情況使用多個(gè)控制器的MVC模式，如圖4所示。

　　在這種模式下，按照程序模塊把界面分成若干個(gè)部分，每個(gè)部分使用一個(gè)控制器來控制。這樣做的好處是程序模塊劃分得很清楚，程序結(jié)構(gòu)更加清晰，也不至于使得一個(gè)控制器過于龐大;缺點(diǎn)是程序的類數(shù)量更多，控制器之前增加了通信開銷。

　　3.3 簡化的MV模式

　　上面的兩種程序設(shè)計(jì)模式已經(jīng)很常見于PC上的應(yīng)用軟件設(shè)計(jì)，包括WEB應(yīng)用或J2EE中的設(shè)計(jì)。但是通常來說，由于基于移動設(shè)備的J2ME應(yīng)用軟件復(fù)雜程度相對PC上的要低許多，有時(shí)候本來就只有幾個(gè)類，如果完全照搬PC上的MVC模式，反而會使程序框架變得更加復(fù)雜。這時(shí)，可以采用以下的一種變形：MV模式(或稱為MC-V或M-VC模式)，如圖5所示。

　　在這種模式中，由于去掉了控制器，于是把控制器的功能合并到View或Model中。如果把Controller合并到View中，則可稱其為M-VC模式;如果把Controller合并到Model中，則可稱其為MC-V模式。

　　3.4 更加簡化的V模式

　　如果認(rèn)為上面這種簡化的MV模式還是過于復(fù)雜，那么可以考慮下面的V模式，如圖6所示。

　　在這種模式中，已經(jīng)完全省略了Model和Controllelr，只剩下View了。界面的切換和數(shù)據(jù)的處理都在各個(gè)界面的View中獨(dú)立完成。這樣使得類的數(shù)量極大地減少，程序執(zhí)行效率有一定的提高，可是從另一個(gè)方面來說，程序的耦合度也增大了。所以，一般來說并不推薦使用這種模式，只有在程序十分簡單、數(shù)據(jù)量很小時(shí)才使用。

　　4 MVC模式應(yīng)用在J2ME上的優(yōu)缺點(diǎn)

　　MVC模式作為一種已成熟應(yīng)用在PC客戶端的設(shè)計(jì)模式，其優(yōu)點(diǎn)是不言而喻的。這些優(yōu)點(diǎn)同樣也在J2ME上得到了很好的體現(xiàn)：

　?、費(fèi)VC最大的優(yōu)點(diǎn)就在于它把一個(gè)應(yīng)用分成了3層，這樣程序設(shè)計(jì)的靈活性就大大增加了。例如，一個(gè)應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只須改動MVC的模型層，而界面表現(xiàn)方式的改變則只須改動MVC的視圖層。

　?、趯VC分離可以讓不同的專家負(fù)責(zé)不同的模塊。一般情況下，M部分由熟悉數(shù)據(jù)庫、網(wǎng)絡(luò)傳輸?shù)膶＜邑?fù)責(zé);V部分則交給對UI有研究的專家。分工意味著可以提高效率并可以按照傳統(tǒng)的責(zé)任劃分來處理軟件開發(fā)過程，使開發(fā)者可以專心于一個(gè)領(lǐng)域，從而極大地提高了軟件開發(fā)的效率。

　?、勰Ｐ偷牟糠?，因?yàn)樽銐虺橄?，可以方便地重?fù)利用，符合OO的思想。另一方面可以利用J2meUnit等單元測試工具對模型進(jìn)行單元測試，以保證工程質(zhì)量。

　　然而MVC模式也存在著一些缺點(diǎn)，而這些缺點(diǎn)在J2ME應(yīng)用上體現(xiàn)得更加明顯：

　?、費(fèi)VC模式應(yīng)用于J2ME上的最大缺點(diǎn)莫過于增大了代碼體積。據(jù)不完全統(tǒng)計(jì)，使用了MVC模式后，代碼體積約是不使用MVC的1.5倍。這對PC上的客戶端軟件來說可能不算什么，可是對于存儲容量十分有限的移動設(shè)備則是致命的。

　?、谀Ｐ?、視圖與控制器分離，它們之間傳遞數(shù)據(jù)時(shí)會耗費(fèi)一定的系統(tǒng)時(shí)間，這或多或少會降低程序的運(yùn)行效率。而程序體積的膨脹也使得J2ME在裝載類時(shí)會耗費(fèi)更多的時(shí)間，也從一定程度上損害了程序的性能。

　?、跰VC的3個(gè)部件定義并不具體，對于3個(gè)部件的具體功能還存在著一些爭議。這給初學(xué)者留下不少的陷阱，加大了使用MVC模式的難度。

　　結(jié)語

　　綜上所述，當(dāng)J2ME應(yīng)用程序比較龐大時(shí)，將MVC設(shè)計(jì)模式應(yīng)用于程序的框架設(shè)計(jì)是一個(gè)不錯(cuò)的選擇;而當(dāng)應(yīng)用程序比較簡單時(shí)，MVC模式的缺點(diǎn)就暴露出來了，這時(shí)可以考慮使用MVC的簡化模式——MV模式，甚至是V模式。目前，筆者已將MVC模式應(yīng)用于J2ME手機(jī)播客軟件中，取得了良好的效果。