伺服器設計模式

1、JAVA 什麼是設計模式，請舉例說明其中一個。

設計模式（Design Patterns）

——可復用面向對象軟體的基礎

設
計模式（Design
pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代
碼可靠性。
毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。項目中合理的運用
設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的核心解決
方案，這也是它能被廣泛應用的原因。

一、設計模式的分類

總體來說設計模式分為三大類：

創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
其實還有兩類：並發型模式和線程池模式。

例子：

單例模式（Singleton）
單例對象（Singleton）是一種常用的設計模式。在Java應用中，單例對象能保證在一個JVM中，該對象只有一個實例存在。這樣的模式有幾個好處：

1、某些類創建比較頻繁，對於一些大型的對象，這是一筆很大的系統開銷。

2、省去了new操作符，降低了系統內存的使用頻率，減輕GC壓力。

3、有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以創建多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易伺服器獨立控制整個流程。

首先我們寫一個簡單的單例類：

[java] view plaincopy

public class Singleton {

/* 持有私有靜態實例，防止被引用，此處賦值為null，目的是實現延遲載入 */
private static Singleton instance = null;

/* 私有構造方法，防止被實例化 */
private Singleton() {
}

/* 靜態工程方法，創建實例 */
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}

/* 如果該對象被用於序列化，可以保證對象在序列化前後保持一致 */
public Object readResolve() {
return instance;
}
}

2、MVC設計模式是什麼？怎麼理解？

什麼是MVP

View ：是指顯示數據並且和用戶交互的層。在安卓中，它們可以是一個Activity，一個Fragment，一個android.view.View或者是一個Dialog。

Model ：是數據源層。比如資料庫介面或者遠程伺服器的api。

Presenter：是從Model中獲取數據並提供給View的層，Presenter還負責處理後台任務。

MVP是一個將後台任務和activities/views/fragment分離的方法，讓它們獨立於絕大多數跟生命周期相關的事件。這樣應用就會變得更簡單，整個應用的穩定性提高10倍以上，代碼也變得更短，可維護性增強，程序員也不會過勞死了~~。

為什麼要在安卓上使用MVP原因一: 盡量簡單

如果你還沒有閱讀過這篇文章，閱讀它: Kiss原則(https://people.apache.org/%7Efhanik/kiss.html)。- kiss是Keep It Stupid Simple或者Keep It Simple, Stupid的縮寫。

.絕大多數的安卓程序都只使用了View-Model架構。

.程序員被絞盡了復雜的界面開發中，而不是解決事務邏輯。

在應用中使用Model-View的壞處是「每個東西之間都是相互關聯的」如下圖:

如果上面的圖解看起來還不夠復雜，那麼想想這些情況：每個view可能在任意的時間出現或者消失，view數據需要保存與恢復，在臨時的view上掛載一個後台任務。

而與「每個東西之間都是相互關聯的」的相反選擇是使用一個萬能對象（god object）。註：god object是指一個對象/常式在系統中做了太多的事情，或者說是有太多不怎麼相關的事情放在一個對象/常式裡面來完成。

god object過於復雜，他的不同部分無法重用、測試，無法輕易的debug和重構。

使用MVP

復雜的任務被分割成簡單的任務。

.更小的對象，更少的bug。

.更好測試

MVP的view層變得如此簡單，在請求數據的時候甚至不需要使用回調。view的邏輯變得非常直接。

原因二: 後台任務

當你需要寫一個Activity，Fragment或者一個自定義View的時候，你可以將所有和後台任務相關的方法放在一個外部的或者靜態的類中。這樣你的後台任務就不會再與Activity相關聯，不會在泄漏內存同時也不會依賴於Activity的重建。我們稱這樣的一個類為「Presenter」。註：要理解此話的含義最好先看懂第一個MVP示例的代碼。

雖然有一些方法可以解決後台任務的問題，但是沒有一種和MVP一樣可靠。

為什麼這是可行的

下面的圖解顯示了在configuration改變或者發生out-of-memory事件的情況下應用的不同部分所發生的事情。每一個開發者都應該知道這些數據，但是這些數據並不好發現。

|  Case 1 | Case 2 |  Case 3

|A configuration| An activity  |  A process

| change  | restart  | restart

---------------------------------------- | ------------- | ------------ | ------------

Dialog | reset |  reset |  reset

Activity, View, Fragment | save/restore  | save/restore | save/restore

Fragment with setRetainInstance(true)  | no change | save/restore | save/restore

Static variables and threads | no change | no change  |  reset

情景1：configuration的改變通常發生在旋轉屏幕，修改語言設置，鏈接外部的模擬器等情況下。要知道更多的configuration change事件請閱讀：configChanges（developer.android.com/reference/android/R.attr.html#configChanges）。

情景2：Activity的重啟發生在當用戶在開發者選項中選中了「Don't keep activities」（「中文下為 不保留活動」）的復選框，然後另一個Activity在最頂上的時候。

情景3：進程的重啟發生在應用運行在後台，但是這個時候內存不夠的情況下。

結論

現在你可以發現，一個擁有setRetainInstance(true)的Fragment並沒有帶來幫助 - 我們還是要保存和/恢復這種fragment的狀態。因此我們可以去掉可保持Fragment的情景，把問題簡單化。Occam's razor（https://en.wikipedia.org/wiki/Occam%27s_razor）

3、設計模式都有哪些?

總體來說設計模式分為三大類：

一、創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

二、結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

三、行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

1、工廠方法模式：

定義一個用於創建對象的介面，讓子類決定實例化哪一個類。Factory Method 使一個類的實例化延遲到其子類。

工廠模式有一個問題就是，類的創建依賴工廠類，也就是說，如果想要拓展程序，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，這就用到工廠方法模式。

創建一個工廠介面和創建多個工廠實現類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的代碼。

2、抽象工廠模式：

提供一個創建一系列相關或相互依賴對象的介面，而無需指定它們具體的類。抽象工廠需要創建一些列產品，著重點在於"創建哪些"產品上，也就是說，如果你開發，你的主要任務是劃分不同差異的產品線，並且盡量保持每條產品線介面一致，從而可以從同一個抽象工廠繼承。

3、單例模式：

單例對象（Singleton）是一種常用的設計模式。在Java應用中，單例對象能保證在一個JVM中，該對象只有一個實例存在。這樣的模式有幾個好處：

（1）某些類創建比較頻繁，對於一些大型的對象，這是一筆很大的系統開銷。

（2）省去了new操作符，降低了系統內存的使用頻率，減輕GC壓力。

（3）有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以創建多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易伺服器獨立控制整個流程。

4、建造者模式：

將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。

5、原型模式：

原型模式雖然是創建型的模式，但是與工程模式沒有關系，從名字即可看出，該模式的思想就是將一個對象作為原型，對其進行復制、克隆，產生一個和原對象類似的新對象。本小結會通過對象的復制，進行講解。在Java中，復制對象是通過clone()實現的，先創建一個原型類。

6、適配器模式：

適配器模式將某個類的介面轉換成客戶端期望的另一個介面表示，目的是消除由於介面不匹配所造成的類的兼容性問題。主要分為三類：類的適配器模式、對象的適配器模式、介面的適配器模式。

7、裝飾器模式：

顧名思義，裝飾模式就是給一個對象增加一些新的功能，而且是動態的，要求裝飾對象和被裝飾對象實現同一個介面，裝飾對象持有被裝飾對象的實例。

8、代理模式：

代理模式就是多一個代理類出來，替原對象進行一些操作，比如我們在租房子的時候回去找中介，為什麼呢？因為你對該地區房屋的信息掌握的不夠全面，希望找一個更熟悉的人去幫你做，此處的代理就是這個意思。

9、外觀模式：

外觀模式是為了解決類與類之家的依賴關系的，像spring一樣，可以將類和類之間的關系配置到配置文件中，而外觀模式就是將他們的關系放在一個Facade類中，降低了類類之間的耦合度，該模式中沒有涉及到介面。

10、橋接模式：

橋接模式就是把事物和其具體實現分開，使他們可以各自獨立的變化。橋接的用意是：將抽象化與實現化解耦，使得二者可以獨立變化，像我們常用的JDBC橋DriverManager一樣。

JDBC進行連接資料庫的時候，在各個資料庫之間進行切換，基本不需要動太多的代碼，甚至絲毫不用動，原因就是JDBC提供統一介面，每個資料庫提供各自的實現，用一個叫做資料庫驅動的程序來橋接就行了。

11、組合模式：

組合模式有時又叫部分-整體模式在處理類似樹形結構的問題時比較方便。使用場景：將多個對象組合在一起進行操作，常用於表示樹形結構中，例如二叉樹，數等。

12、享元模式：

享元模式的主要目的是實現對象的共享，即共享池，當系統中對象多的時候可以減少內存的開銷，通常與工廠模式一起使用。

13、策略模式：

策略模式定義了一系列演算法，並將每個演算法封裝起來，使其可以相互替換，且演算法的變化不會影響到使用演算法的客戶。需要設計一個介面，為一系列實現類提供統一的方法，多個實現類實現該介面，設計一個抽象類（可有可無，屬於輔助類），提供輔助函數。

14、模板方法模式：

一個抽象類中，有一個主方法，再定義1...n個方法，可以是抽象的，也可以是實際的方法，定義一個類，繼承該抽象類，重寫抽象方法，通過調用抽象類，實現對子類的調用。

15、觀察者模式：

觀察者模式很好理解，類似於郵件訂閱和RSS訂閱，當我們瀏覽一些博客或wiki時，經常會看到RSS圖標，就這的意思是，當你訂閱了該文章，如果後續有更新，會及時通知你。

其實，簡單來講就一句話：當一個對象變化時，其它依賴該對象的對象都會收到通知，並且隨著變化！對象之間是一種一對多的關系。

16、迭代子模式：

顧名思義，迭代器模式就是順序訪問聚集中的對象，一般來說，集合中非常常見，如果對集合類比較熟悉的話，理解本模式會十分輕松。這句話包含兩層意思：一是需要遍歷的對象，即聚集對象，二是迭代器對象，用於對聚集對象進行遍歷訪問。

17、責任鏈模式：

責任鏈模式，有多個對象，每個對象持有對下一個對象的引用，這樣就會形成一條鏈，請求在這條鏈上傳遞，直到某一對象決定處理該請求。但是發出者並不清楚到底最終那個對象會處理該請求，所以，責任鏈模式可以實現，在隱瞞客戶端的情況下，對系統進行動態的調整。

18、命令模式：

命令模式的目的就是達到命令的發出者和執行者之間解耦，實現請求和執行分開。

19、備忘錄模式：

主要目的是保存一個對象的某個狀態，以便在適當的時候恢復對象，個人覺得叫備份模式更形象些，通俗的講下：假設有原始類A，A中有各種屬性，A可以決定需要備份的屬性，備忘錄類B是用來存儲A的一些內部狀態，類C呢，就是一個用來存儲備忘錄的，且只能存儲，不能修改等操作。

20、狀態模式：

狀態模式在日常開發中用的挺多的，尤其是做網站的時候，我們有時希望根據對象的某一屬性，區別開他們的一些功能，比如說簡單的許可權控制等。

21、訪問者模式：

訪問者模式把數據結構和作用於結構上的操作解耦合，使得操作集合可相對自由地演化。訪問者模式適用於數據結構相對穩定演算法又易變化的系統。因為訪問者模式使得演算法操作增加變得容易。

若系統數據結構對象易於變化，經常有新的數據對象增加進來，則不適合使用訪問者模式。訪問者模式的優點是增加操作很容易，因為增加操作意味著增加新的訪問者。訪問者模式將有關行為集中到一個訪問者對象中，其改變不影響系統數據結構。其缺點就是增加新的數據結構很困難。

22、中介者模式：

中介者模式也是用來降低類類之間的耦合的，因為如果類類之間有依賴關系的話，不利於功能的拓展和維護，因為只要修改一個對象，其它關聯的對象都得進行修改。

如果使用中介者模式，只需關心和Mediator類的關系，具體類類之間的關系及調度交給Mediator就行，這有點像spring容器的作用。

23、解釋器模式：

解釋器模式一般主要應用在OOP開發中的編譯器的開發中，所以適用面比較窄。

(3)伺服器設計模式擴展資料：

介紹三本關於設計模式的書：

1、《設計模式：可復用面向對象軟體的基礎》

作者：[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

出版社： 機械工業出版社

2、《軟體秘笈：設計模式那點事》

作者：鄭阿奇

出版社：電子工業出版社

3、《設計模式：基於C#的工程化實現及擴展》

作者：王翔

出版社：電子工業出版社

4、C# 框架是什麼？MVC是什麼 ？工廠模式是什麼？設計模式是什麼？三層架構是什麼？天天聽別人說起就不知道。

C# 框架看這里
http://download.csdn.net/source/2578425

MVC是三個單詞的縮寫,分別為： 模型(Model),視圖(View)和控制Controller)。 MVC模式的目的就是實現Web系統的職能分工。 Model層實現系統中的業務邏輯，通常可以用JavaBean或EJB來實現。 View層用於與用戶的交互，通常用JSP來實現。 Controller層是Model與View之間溝通的橋梁，它可以分派用戶的請求並選擇恰當的視圖以用於顯示，同時它也可以解釋用戶的輸入並將它們映射為模型層可執行的操作。
http://ke.baidu.com/view/31.htm

工廠模式定義：提供創建對象的介面.
工廠模式是我們最常用的模式了,著名的Jive論壇 ,就大量使用了工廠模式，工廠模式在Java程序系統可以說是隨處可見。
工廠模式如此常用，因為工廠模式就相當於創建實例對象的new，我們經常要根據類Class生成實例對象，如A a=new A() 工廠模式也是用來創建實例對象的，所以以後new時就要多個心眼，是否可以考慮使用工廠模式，雖然這樣做，可能多做一些工作，但會給你系統帶來更大的可擴展性和盡量少的修改量。
http://ke.baidu.com/view/1306799.htm

設計模式是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。
http://ke.baidu.com/view/66964.htm

三層架構，通常意義上的三層架構就是將整個業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。區分層次的目的即為了「高內聚，低耦合」的思想。
http://ke.baidu.com/view/687468.htm

5、請問設計模式和框架是什麼？》

框架模式和設計模式的區別

框架、設計模式這兩個概念總容易被混淆，其實它內們之間還是有區別容的。框架通常是代碼重用，而設計模式是設計重用，架構則介於兩者之間，部分代碼重用，部分設計重用，有時分析也可重用。在軟體生產中有三種級別的重用：內部重用，即在同一應用中能公共使用的抽象塊;代碼重用，即將通用模塊組合成庫或工具集，以便在多個應用和領域都能使用；應用框架的重用，即為專用領域提供通用的或現成的基礎結構，以獲得最高級別的重用性。
框架與設計模式雖然相似，但卻有著根本的不同。設計模式是對在某種環境中反復出現的問題以及解決該問題的方案的描述，它比框架更抽象；框架可以用代碼表示，也能直接執行或復用，而對模式而言只有實例才能用代碼表示;設計模式是比框架更小的元素，一個框架中往往含有一個或多個設計模式，框架總是針對某一特定應用領域，但同一模式卻可適用於各種應用。可以說，框架是軟體，而設計模式是軟體的知識。

6、試問設計模式、架構模式和架構風格的異同點

架構模式從子復系統或模塊、及制其之間的關系層次上描述了粗粒度的解決方案。
架構風格是描述某一特定應用領域中系統組織方式的慣用模式，是系統主要的、組織性的設計。
風格是模式的外在表現。

三者的共同點是都用於設計，是一套可重用的方法套路。不同點：前二者的不同點在於粒度，設計模式定義出子系統或組件的微觀結構，結架構模式則從子系統或模塊、及其之間的關系層次上描述了粗粒度的解決方案；後二者的區別在於前者著重描述系統的內部組織，後者著重於描述結構的外在表現。

7、mvc設計模式和mvc框架的區別

之前總是混淆MVC表現模式和三層架構模式，為此記錄下。
三層架構和MVC是有明顯區別的,MVC應該是展現模式(三個加起來以後才是三層架構中的UI層) 三層架構(3-tier application) 通常意義上的三層架構就是將整個業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。區分層次的目的即為了「高內聚，低耦合」的思想。 1、表現層（UI）：通俗講就是展現給用戶的界面，即用戶在使用一個系統的時候他的所見所得。 2、業務邏輯層（BLL）：針對具體問題的操作，也可以說是對數據層的操作，對數據業務邏輯處理。 3、數據訪問層（DAL）：該層所做事務直接操作資料庫，針對數據的增添、刪除、修改、更新、查找等。
MVC是 Model-View-Controller，嚴格說這三個加起來以後才是三層架構中的UI層，也就是說，MVC把三層架構中的UI層再度進行了分化，分成了控制器、視圖、實體三個部分，控制器完成頁面邏輯，通過實體來與界面層完成通話；而C層直接與三層中的BLL進行對話。
mvc可以是三層中的一個表現層框架，屬於表現層。三層和mvc可以共存。 三層是基於業務邏輯來分的，而mvc是基於頁面來分的。 MVC主要用於表現層，3層主要用於體系架構，3層一般是表現層、中間層、數據層，其中表現層又可以分成M、V、C，(Model View Controller)模型－視圖－控制器
曾把MVC模式和Web開發中的三層結構的概念混為一談，直到今天才發現一直是我的理解錯誤。MVC模式是GUI界面開發的指導模式，基於表現層分離的思想把程序分為三大部分：Model-View-Controller，呈三角形結構。Model是指數據以及應用程序邏輯，View是指 Model的視圖，也就是用戶界面。這兩者都很好理解，關鍵點在於Controller的角色以及三者之間的關系。在MVC模式中，Controller和View同屬於表現層，通常成對出現。Controller被設計為處理用戶交互的邏輯。一個通常的誤解是認為Controller負責處理View和Model的交互，而實際上View和Model之間是可以直接通信的。由於用戶的交互通常會涉及到Model的改變和View的更新，所以這些可以認為是Controller的副作用。
MVC是表現層的架構，MVC的Model實際上是ViewModel，即供View進行展示的數據。 ViewModel不包含業務邏輯，也不包含數據讀取。 而在N層架構中，一般還會有一個Model層，用來與資料庫的表相對應，也就是所謂ORM中的O。這個Model可能是POCO，也可能是包含一些驗證邏輯的實體類，一般也不包含數據讀取。進行數據讀取的是數據訪問層。而作為UI層的MVC一般不直接操作數據訪問層，中間會有一個業務邏輯層封裝業務邏輯、調用數據訪問層。UI層（Controller）通過業務邏輯層來得到數據（Model），並進行封裝（ViewModel），然後選擇相應的View。
MVC本來是存在於Desktop程序中的，M是指數據模型，V是指用戶界面，C則是控制器。使用MVC的目的是將M和V的實現代碼分離，從而使同一個程序可以使用不同的表現形式。比如一批統計數據你可以分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步，一旦M改變，V應該同步更新。 MVC如何工作 MVC是一個設計模式，它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務。 視圖V 視圖是用戶看到並與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術已層出不窮，它們包括Macromedia Flash和象XHTML，XML/XSL，WML等一些標識語言和Web services. 如何處理應用程序的界面變得越來越有挑戰性。MVC一個大的好處是它能為你的應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發生，不管這些數據是聯機存儲的還是一個雇員列表，作為視圖來講，它只是作為一種輸出數據並允許用戶操縱的方式。 模型M 模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。被模型返回的數據是中立的，就是說模型與數據格式無關，這樣一個模型能為多個視圖提供數據。由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。 控制器C 控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求。所以當單擊Web頁面中的超鏈接和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然後再確定用哪個視圖來顯示返回的數據。
模型Model 模型是應用程序的主體部分。模型表示業務數據，或者業務邏輯. 實現具體的業務邏輯、狀態管理的功能。 視圖View 視圖是應用程序中用戶界面相關的部分，是用戶看到並與之交互的界面。 就是與用戶實現交互的頁面，通常實現數據的輸入和輸出功能。 控制器controller 控制器工作就是根據用戶的輸入，控制用戶界面數據顯示和更新model對象狀態。起到控制整個業務流程的作用，實現View層跟Model層的協同工作。
3層架構指:表現層(顯示層) 業務邏輯層 數據訪問層(持久化)如果大家非要「生搬硬套」把它和MVC扯上關系話那我就只能在這里"強扭這個瓜"了即: V 3層架構中"表現層"aspx頁面對應MVC中View(繼承的類不一樣) C 三層架構中"表現層"的aspx.cs頁面(類)對應MVC中的Controller,理解這一點並不難，大家想一想我們以前寫過的 Redirect，當然它本身就是跳轉了一些鏈接頁面，而MVC中的Controller要做的更爽，它控制並顯示輸出了一個視圖。即然所起到的作用都是對業務流程和顯示信息的控制，只不過是實現手段不同而已。 M 3層架構中業務邏輯層和數據訪問層對應MVC中Model(必定View和Controller已找到「婆家」剩下Model只能是業務邏輯層和數據訪問層了)
為什麼要使用 MVC 大部分Web應用程序都是用像ASP，PHP，或者CFML這樣的過程化(自PHP5.0版本後已全面支持面向對象模型)語言來創建的。它們將像資料庫查詢語句這樣的數據層代碼和像HTML這樣的表示層代碼混在一起。經驗比較豐富的開發者會將數據從表示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。盡管構造MVC應用程序需要一些額外的工作，但是它給我們帶來的好處是無庸質疑的。 首先，最重要的一點是多個視圖能共享一個模型，現在需要用越來越多的方式來訪問你的應用程序。對此，其中一個解決之道是使用MVC，無論你的用戶想要Flash界面或是 WAP 界面；用一個模型就能處理它們。由於你已經將數據和業務規則從表示層分開，所以你可以最大化的重用你的代碼了。 由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同界面使用。例如，很多數據可能用HTML來表示，但是它們也有可能要用Adobe Flash和WAP來表示。模型也有狀態管理和數據持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。 因為模型是自包含的，並且與控制器和視圖相分離，所以很容易改變你的應用程序的數據層和業務規則。如果你想把你的資料庫從MySQL移植到Oracle，或者改變你的基於RDBMS數據源到LDAP，只需改變你的模型即可。一旦你正確的實現了模型，不管你的數據來自資料庫或是LDAP伺服器，視圖將會正確的顯示它們。由於運用MVC的應用程序的三個部件是相互獨立，改變其中一個不會影響其它兩個，所以依據這種設計思想你能構造良好的松耦合的構件。 對我來說，控制器也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶。
拿一個簡單的登陸模塊說，需求是你輸入一個用戶名、密碼，如果輸入的跟預先定義好的一樣，那麼就進入到正確頁面，如果不一樣，就提示個錯誤信息「你Y別在這兒蒙我，輸入的不對！」。 V 這個小小的模塊中，起始的輸入用戶名密碼的頁面跟經過校驗後顯示的頁面就相當於View C 而這里還需要一個controller頁面，就是用於接收輸入進來的用戶名密碼，還有經過校驗後返回的一個flg（此flg就是用於判斷你輸入的是否正確，而跳轉到相應的頁面的） M 最後還缺一個Model，那麼就是你那個用於校驗的類了，他就是處理你輸入的是否跟預先訂好的一樣不一樣的，之後返回一個flg。 這樣就完全實現了邏輯跟頁面的分離，我頁面不管你咋整，反正我就一個顯示，而controller呢也不管你Model咋判斷對不對，反正我給你了用戶名跟密碼，你就得給我整回來一個flg來，而Medol呢，則是反正你敢給我個用戶名跟密碼，我就給你整過去個flg
m 提供數據，數據之間的關系，轉化等。並可以通知視圖和控制器自己哪些地方發生了變化。 v 提供顯示，能根據m的改變來更新自己 c 比如視圖做了點擊一個按鈕，會先發給這個視圖的控制器，然後這個控制器來決定做什麼操作(讓模型更新數據，控制視圖改變) mvc是一個復合模式 mv，mc都是觀察者模式 m內部的組件組合模式 vc之間是策略模式(可以隨時更換不同的控制器)
MVC模式是上世紀70年代提出，最初用於Smalltalk平台上的。 MVC是表現模式，是用來向用戶展現的許多組建的一個模式（UI/Presentation Patten） MVC有三種角色： Model：用來儲存數據的組件（與領域模型概念不同，兩者會相互交叉） View：從Model中獲取數據進行內容展示的組件。同樣的Model在不同的View下可展示不同的效果。獲取Model的狀態，而不對其進行操作。 Controller：接受並處理用戶指令（操作Model（業務）），選擇一個View進行操作。
MVC概述：協作 存在單向引用，例如Model不知道View和Controller的存在。View不知道Controller的存在。這就隔離了表現和數據。View和controller是單向引用。而實際中View和Controller也是有數據交互的。
MVC的重要特點是分離。兩種分離： View和數據(Model)的分離 使用不同的View對相同的數據進行展示；分離可視和不可視的組件，能夠對Model進行獨立測試。因為分離了可視組件減少了外部依賴利於測試。（資料庫也是一種外部組件） View和表現邏輯(Controller)的分離 Controller是一個表現邏輯的組件，並非一個業務邏輯組件。MVC可以作為表現模式也可以作為建構模式，意味這Controller也可以是業務邏輯。分離邏輯和具體展示，能夠對邏輯進行獨立測試。
MVC和三層架構 MVC與三層架構類似么？ View-UI Layer | Controller-Bussiness Layer | Model-Data Access Layer 其實這樣是錯誤的 MVC是表現模式（Presentation Pattern） 三層架構是典型的架構模式（Architecture Pattern） 三層架構的分層模式是典型的上下關系，上層依賴於下層。但MVC作為表現模式是不存在上下關系的，而是相互協作關系。即使將MVC當作架構模式，也不是分層模式。MVC和三層架構基本沒有可比性，是應用於不同領域的技術。
MVC模式與三層架構:
ui (view)←(contorller)
***********************
bll (model)
***********************
dal (model)

8、java中常用的設計模式有哪些？

1.單例模式（有的書上說叫單態模式其實都一樣）
該模式主要目的是使內存中保持1個對象
2.工廠模式
該模式主要功能是統一提供實例對象的引用。看下面的例子：
public class Factory{
public ClassesDao getClassesDao(){
ClassesDao cd = new ClassesDaoImpl();
return cd;
}
}
interface ClassesDao{
public String getClassesName();
}
class ClassesDaoImpl implements ClassesDao {
public String getClassesName(){
System.out.println("A班");
}
}
class test
{
public static void main(String[] args){
Factory f = new Factory();
f.getClassesDao().getClassesName();
}
}
這個是最簡單的例子了，就是通過工廠方法通過介面獲取對象的引用
3.建造模式
該模式其實就是說，一個對象的組成可能有很多其他的對象一起組成的，比如說，一個對象的實現非常復雜，有很多的屬性，而這些屬性又是其他對象的引用，可能這些對象的引用又包括很多的對象引用。封裝這些復雜性，就可以使用建造模式。
4.門面模式
這個模式個人感覺像是Service層的一個翻版。比如Dao我們定義了很多持久化方法，我們通過Service層將Dao的原子方法組成業務邏輯，再通過方法向上層提供服務。門面模式道理其實是一樣的。
5.策略模式
這個模式是將行為的抽象，即當有幾個類有相似的方法，將其中通用的部分都提取出來，從而使擴展更容易。

9、軟體開發中什麼是C/S和B/S設計模式？

CS結構安裝後使用、有窗體界面 效率高；維護升級繁瑣、需要安裝。比如QQ

BS結構無需安裝、瀏覽器訪問 ；客戶無需安裝和升級，依賴網路。比如web QQ

10、Java常用的幾種設計模式

下面給你介紹5種設計模式：

1.單例設計模式

所謂單例設計模式簡單說就是無論程序如何運行，採用單例設計模式的類（Singleton類）永遠只會有一個實例化對象產生。具體實現步驟如下：

(1) 將採用單例設計模式的類的構造方法私有化（採用private修飾）。

(2) 在其內部產生該類的實例化對象，並將其封裝成private static類型。

(3) 定義一個靜態方法返回該類的實例。

2.工廠設計模式

程序在介面和子類之間加入了一個過渡端，通過此過渡端可以動態取得實現了共同介面的子類實例化對象。

 3.代理設計模式

指由一個代理主題來操作真實主題，真實主題執行具體的業務操作，而代理主題負責其他相關業務的處理。比如生活中的通過代理訪問網路，客戶通過網路代理連接網路（具體業務），由代理伺服器完成用戶許可權和訪問限制等與上網相關的其他操作（相關業務）。

 4.觀察者設計模式

所謂觀察者模式，舉個例子現在許多購房者都密切觀察者房價的變化，當房價變化時，所有購房者都能觀察到，以上的購房者屬於觀察者，這便是觀察者模式。

java中可以藉助Observable類和Observer介面輕松實現以上功能。當然此種模式的實現也不僅僅局限於採用這兩個類。

 5.適配器模式

如果一個類要實現一個具有很多抽象方法的介面，但是本身只需要實現介面中的部分方法便可以達成目的，所以此時就需要一個中間的過渡類，但此過渡類又不希望直接使用，所以將此類定義為抽象類最為合適，再讓以後的子類直接繼承該抽象類便可選擇性的覆寫所需要的方法，而此抽象類便是適配器類。