您现在的位置：程式碼之家 >> 編程語言 > >> Java 程式設計 >> J2ME

MVC 模式在 J2ME 專案實戰應用（一）：核心原理、常見變體與架構決策

編輯：J2ME

MVC 起源與核心思想

MVC (Model-View-Controller) 由 Trygve Reenskaug 於 1979 年 Smalltalk-79 專案提出，核心只有一個字：**分離**。

Model：領域實體與業務規則（資料庫、網路、RMS、演算法）
View：Model 在螢幕上的視覺投影（Canvas、Form、List、自繪圖形）
Controller：協調者，處理使用者輸入、驅動 Model 變更、選擇 View 更新

分離帶來三大收益：專業分工、UI 變更隔離、Model 可重用可測試。

MVC 在 J2ME 的特殊挑戰

J2ME 常見 MVC 變體對比

變體一：Model-View (MV / MC-V / M-VC)

特徵：以螢幕為單位，每個 Canvas/Form 內嵌私有 Model 物件，Controller 責任被 View 或 Model 吸收。

class MyScreen extends Form {
    private ScreenModel model; // 只服務此畫面
    MyScreen(ScreenModel m) { this.model = m; append(new StringItem(model.getTitle())); }
}

優點：直觀、適合 RAD 工具、類別數少
缺點：思維陷阱——從 UI 出發設計，忽略業務流程；Model 被切碎難以重用；Controller 邏輯分散在 View/Model 邊界模糊
代表：MingJava 站長教學範例、多數 WTK 範例

變體二：Sun Blueprint Smart Ticket —— 巨大 Controller (Dispatcher)

特徵：單一 Controller 類，內含巨大 switch-case 或 if-else 處理所有 UI 事件（命令、按鍵、清單選擇），常數定義畫面 ID。

優點：集中管理畫面導航、MIDP 1→2 遷移只改 View 層
缺點：Controller 膨脹難維護、違反單一職責、新增畫面必改核心類
評價：針對 MIDP 導航痛點的實用妥協，非最佳實踐

變體三：iFeedback —— 退化單類封裝

public abstract class MVCComponent implements CommandListener {
    protected abstract void initModel();    // M
    protected abstract void createView();   // V
    protected abstract void updateView();   // V
    public abstract void commandAction(Command c, Displayable s); // C
    // 內建 prepareScreen/showScreen 生命週期
}

優點：極少類別、三位一體
缺點：本質上放棄分離，M/V/C 邏輯糾纏在方法裡，複雜度稍增即失控
定位：極小專案、快速原型、教學示範

作者推薦：UML 標準四層架構（Boundary-Control-Entity-Locator）

BCEL 四層架構圖

命名慣例與職責邊界

挑戰	影響	應對策略
類別數量膨脹	JAR 體積、載入時間增加	合併細粒度 Controller、共用 Base 類、ProGuard 混淆壓縮
記憶體極限	多層物件參考佔用堆疊	惰性初始化、場景級釋放、物件池
單執行緒 UI 模型	Controller 不能阻塞事件派發執行緒	耗時操作放入背景 Thread、Callback 回 UI 執行緒
畫面導航複雜	Controller 易變成「上帝類」	導航邏輯獨立為 Navigator/Router、狀態機管理

層級	後綴	對應 MVC	核心職責
Boundary (View)	`UI`	View	畫面構建、使用者輸入收集、回調 Controller 方法、零業務邏輯
Controller (Workflow)	`Workflow`	Controller	接收 UI 回調、協調 Locator/Entity、業務流程編排、狀態機管理
Entity (Model)	`Entity` / 無	Model	純資料結構、getter/setter、序列化、業務規則驗證、零持久化邏輯
Locator (Lifecycle)	`Locator`	Model 輔助	Entity 的 CRUD、RMS/檔案/網路持久化、查詢、快取、單例管理

協作流程：以「編輯記事」為例

用戶在 NoteEditUI 輸入內容，按「儲存」命令
NoteEditUI.commandAction() → 呼叫 noteEditWorkflow.saveNote()
NoteEditWorkflow.saveNote() → 從 UI 取得資料 → 建立/更新 NoteEntity
NoteEditWorkflow → 呼叫 NoteLocator.save(note) → RMS 持久化
成功 → NoteEditWorkflow 通知 NoteEditUI 返回列表 → NoteManagerUI.refresh()

關鍵隔離：UI 不知 RMS、Locator 不知 UI、Entity 不知持久化細節。依賴方向單向向內，最內層 Entity 最純粹、最可重用。

基礎抽象類實現

// BaseView.java
public abstract class BaseView {
    public abstract Display getDisplay();
    public abstract Displayable getScreen();
    protected abstract void createView() throws Exception;
    public abstract void updateView() throws Exception;
    public abstract BaseController getController();

    public Displayable prepareScreen() throws Exception {
        if (getScreen() == null) createView(); else updateView();
        return getScreen();
    }
    public void displayScreen() {
        try { getDisplay().setCurrent(prepareScreen()); }
        catch (Exception e) { showErrorAlert(e); }
    }
}

// BaseController.java
public abstract class BaseController {
    public abstract BaseView getView();
    public abstract void setView(BaseView view);
}

構造時雙向綁定：new NoteEditUI(workflow); workflow.setView(ui);

架構決策清單：新專案如何選擇？

專案規模/性質	推薦架構	理由
單一畫面、<5 類、一次性專案	iFeedback 單類 / 簡單 MV	開發速度優先，維護成本可控
多畫面、表單導向、需快速迭代 UI	Sun Smart Ticket Dispatcher	導航集中管理，View 可整體替換
中大型、複雜業務邏輯、長期維護、團隊協作	BCEL 四層 (本文推薦)	職責清晰、可測試、可擴展、新人上手快
遊戲專案（主迴圈、狀態機）	遊戲專用：GameLoop + StateMachine + EntitySystem	MVC 不適合遊戲幀級更新，需 ECS/狀態機架構

結語

MVC 非銀彈，而是管理複雜度的框架契約。在 J2ME 這樣資源受限、API 低階的平台上，盲目套用桌面/網頁 MVC 會帶來沉重負擔。關鍵在於：理解分離的本質、識別專案真實痛點、選擇適合當下的變體、建立團隊共識的命名與協作規範。下一篇將以完整記事本專案，示範 BCEL 四層架構的落地細節與代碼實戰。