我們所開發(fā)的應用程序大多需要提供一個圖形用戶界面（GUI）。關于GUI應用的架構設計，已經有了很多模式，比如Martin Fowler的blog 中有一篇“GUI Architectures”，里面介紹了Form & Control、MVC、MVP、Passive View、Presentation Model、Supervising Controller、Event Aggregator，Observer Synchronization 等多種模式。模式可以幫助我們建立大連OA系統(tǒng)二次開發(fā)需要注意的代碼架構，但前提是弄清楚模式的應用場景。這些模式自然不是憑空產生的，都是為了解決具體的問題。模式在實現(xiàn)上的差別，通常都體現(xiàn)了在約束間的不同取舍以及問題的差別。弄清楚GUI應用面臨的設計上的問題，有助于我們正確地挑選設計方案。下面我們來看一些GUI應用常見的設計問題。
致遠服軟認為：http://www.soft8.com.cn/第一個問題就是界面的變化和業(yè)務的變化頻率不同，通常是界面變化更頻繁，而我們希望一方的變化不至于影響另一方的邏輯。對于這個問題，一個自然的解決方案就是分離界面顯示邏輯和后臺業(yè)務邏輯。MVC 和 MVP 都涉及到了這一點，它們的共同特點就是把 View和應用程序的其他部分分開了。這是一個關鍵的分離，從此之后應用被分為兩部分，拋開它們彼此可以獨立的變化不說，最大的好處是這兩部分的問題也可以分而治之。應用程序的其他部分有自己的問題和方案，不在我們討論范圍內。我們后面將聚焦在View和相關的顯示邏輯方面的問題。
當然這種分離也不是沒有代價的，一個立即出現(xiàn)的問題就是 View 如何更新。MVC 和MVP把View分出來制造了這個問題，它們同時也提供了大連OA系統(tǒng)二次開發(fā)需要注意的代碼架構解決這個問題。MVP中Presenter完成業(yè)務邏輯后可以拿到最新的Model，它可以操控視圖，根據(jù)最新的Model來設置視圖的各種屬性并刷新。
MVC中Controller在完成協(xié)助車輛直線運行軟件開發(fā)邏輯操作后更新Model，Model變化時可以發(fā)出事件，View訂閱 Model 更新事件來更新自己。MVC 有各種變體，一種是 Controller 直接把 Model 推給View，View自己從Model中取出感興趣的數(shù)據(jù)來刷新自己。
對視圖更新的處理是 MVC 和 MVP 在實現(xiàn)上的主要區(qū)別。MVP 中 View 不需要知道Model，Presenter直接操作View；MVC中View知道Model，自己根據(jù)Model來更新自己的狀態(tài)。
跟大連OA系統(tǒng)二次開發(fā)需要注意的代碼架構相關的另一個常見問題就是可測試性。即使其他分出去的部分可以獨立測試，但剩下來的View依然Hold住了一部分顯示相關的邏輯。顯示邏輯也是邏輯，也需要測試，而通常直接測試 GUI界面是相對難以測試的?，F(xiàn)有直接測試 GUI的測試工具都面臨以下問題。
