一、簡介

    一般應用中用戶界面的變化相對較為頻繁 ， 有時需要支持多種表現(xiàn)模式（如 WEB 客戶端和 GUI 客戶端），但是數(shù)據(jù)和業(yè)務邏輯相對保持穩(wěn)定。

    MVC（Model-View-Controller） 模式是一種常用的設計模式 ，MVC 將模型 ， 顯示和控制進行了分離，可以使得應用更加方便實現(xiàn)對多種表現(xiàn)模式的支持及降低表現(xiàn)形式修改對整體系統(tǒng)的影響。由于本文重點討論的是 MVC 中的通知機制，至于 MVC 的其它內(nèi)容可以參考其它相關文檔。 

圖表一MVC模式

二、MVC的通知機制

    上圖是在 SUN 的 J2EE BluePRints 中關于 MVC 模式的描述 ， 在實現(xiàn) MVC 模式時首先應該注重的是模型與視圖之間的關系。在這些關系中尤其值得大家注重的是模型通知視圖，假如不能正確的設計這個通知機制（模型與視圖之間關聯(lián)實現(xiàn)通知）便會完全違反 MVC 的設計初衷。 MVC 模式的其中一個目的在于使模式獨立與視圖，然而不正確的理解和設計通知機制會導致模型和試圖的依靠性。

    2.1     采用 Observer 模式實現(xiàn)通知機制既要實現(xiàn)模式到視圖的通知機制，同時有要確保實現(xiàn)模型與視圖的分離。通常我們可以通過Observer模式來實現(xiàn)這樣的通知機制。

    圖表2 Observer模式

    視圖實現(xiàn) Observer 接口，并向模型注冊，模型通過調(diào)用所維護的觀察者的實例調(diào)用 Update 方法來通知視圖進行刷新。可見， Observer 接口有效的實現(xiàn)了模型和視圖間的耦合性的分離。

    2.2     模型通知視圖還是控制器通知視圖

    圖表 3 基于 MVC 的 J2EE 應用

    在將 MVC 模式應用于的總體結構時，經(jīng)常會有是模型通知視圖還是控制器通知視圖的問題，其實我認為這個問題完全取決于對系統(tǒng)各個部分的劃分和理解，假如我們把模型層更多劃分為數(shù)據(jù)實體 （ 如： Entity Bean） 則可能會發(fā)現(xiàn)，其實我們的通知機制是不能由模型部分來完成的，而是由我們的控制器來完成的。這種劃分好象有些違反了 MVC 模式，但實事上非凡是一些想要同時支持 B/S 和 C/S 的 J2EE 應用，控制器和模式通知機制經(jīng)常有較大的耦合性（ C/S 結構中，客戶完全通過會話 Bean 來完成業(yè)務），可能有時在一起實現(xiàn)更好。

    總之，更好的內(nèi)聚性和更松散的耦合性才是架構設計的重點，應該做出適合自身應用的 MVC 架構。

三、結束語

    MVC 模式的要害在于分離易變和不易變部分間的耦合性，所以在應用 MVC 模式時一定要注重解耦才是要害，同時一定要更據(jù)具體的使用環(huán)境進行調(diào)整，不要生搬硬套，如 Microsoft 的 MFC 采用的 Document-view 就是 MVC 的變體，它把控制器合并到視圖中，這是因為考慮了視圖與控制器緊耦合的影響。

【參考文獻】

1．  Sun Microsystem ， J2EE BluePrints

2．  GOF,Design Patterns, 機械工業(yè)出版社， 2002

作者：

蔡超，貴州大學，計算機軟件與理論，碩士