先說優點:
1)分離M.V.C允許不同的專家負責不同的模塊。壹般來說，M部分由熟悉數據庫和網絡傳輸的專家負責；v是給對UI有研究的專家的。這對於項目經理來說是多麽的誘人，分工意味著可以提高效率，可以按照傳統的職責分工來處理軟件開發過程。對於開發者來說，他們也可以專註於壹個領域。這樣做的前提是界面要清晰，MVC的分離思想正在為其提供基礎。
2)壹旦V的部分發生變化，可以快速重構，不會造成整個項目的返工。現在軟件表示層的壹些變化真的太快了…
3)M部分，因為足夠抽象，可以很容易的重用，符合OO的思想。另壹方面，我們可以使用JUnit和其他單元測試工具來測試M，以確保工程質量。
說完優點，我們來看看缺點:
1)使用MVC模式(包括其他現代模式)暗示著我們可以通過生成更多的類來提高程序的可讀性和健壯性。附帶的缺點是班級數量的擴大。講個笑話，MVC就像面團制作用的速效粉壹樣，是最方便的代碼擴展器。相信大家都深有體會:)
2)雖然2)MVC定義了M.V.C各個組件的含義，但並不具體，它們之間也沒有明確的聯系。於是在除了View之外的其他方面出現了很多爭論，大家都想把自己的理解作為正解。特別是“模型是屏幕數據的集合還是實體數據的集合”和“控制器的角色”是兩個經常爭論的問題。如前所述，MVC的品種很多，這也給初學者留下了很多陷阱。將舉例分析幾種常見的做法。
3)3)MVC的實現成本高。但是請註意，這是相對的。壹般來說，項目越大，越能看出它的優勢。
通用MVC模式實踐
下面將介紹midp平臺上幾種常見的做法，最後是我習慣的做法。
M-v形式(或MC-v，m-VC)
這也是j2me中常用的方法。總而言之，這種方法以屏幕為組織單位，所以非常適合RAD工具的開發。壹個屏幕及其控件被抽象成壹個VC類，這個類中有壹個私有的模型對象來表示屏幕上要使用的數據元素。屏幕對象不存儲任何實體數據，這些數據組織在模型對象中。大概是因為屏幕對象比較直觀，控制器的功能不太明確(它的大部分功能都被視圖或者模型代替了，看妳的實現了)，所以經常被稱為模型-視圖模式。其形式如下:
類MyFrame擴展框架{
私人模特模特；
私有StringItem名稱；
我的框架(模型模型){
this.model = model
name = new StringItem(model . getname())；//請求模型的數據
追加(名稱)；
}
}
班級模型{
私有字符串name="M-C模式"；
Public String getName(){//這是壹個服務接口。
返回名稱；
}
}
上面看到的是典型的M-V模型，我們可以理解這種以屏幕為中心的分離的意義。Model組織屏幕上的數據，view向Model請求它想要顯示的數據。註意，這個操作必須通過預先協商好的接口訪問，不能直接操作。如果有壹個復雜的事務邏輯(用戶選擇的壹個操作)，有人放在模型端，有人放在視圖端，但壹般都是放在模型端，然後模型就有了嚴重的控制器色彩。
這種形式的優點是非常直觀，而且它還以有限的方式將顯示和數據分開。如果妳經常閱讀j2medev.com站長Mingjava的文章，妳可以看到他寫的大多數例子都是這種模式。這種模式經常在RAD工具中使用。
這種模式的缺點是，它鼓勵妳像RAD tools壹樣從屏幕上思考，這往往會讓妳陷入RAD的陷阱——不首先考慮事務的流程，而是直接從用戶界面上分析問題，這往往會扼殺妳的整體想法。