android 設計模式

MVC英文即Model-View-Controller，即把一個應用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離，這樣一個應用被分紅三個層——模型層、視圖層、控制層。

模型
　　模型(Model)：就是業務流程/狀態的處理以及業務規則的制定。業務流程的處理過程對其它層來講是黑箱操做，模型接受視圖請求的數據，並返回最終的處理結果。業務模型的設計能夠說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應用例子，它從應用技術實現的角度對模型作了進一步的劃分，以便充分利用現有的組件，但它不能做爲應用設計模型的框架。它僅僅告訴你按這種模型設計就能夠利用某些技術組件，從而減小了技術上的困難。對一個開發者來講，就能夠專一於業務模型的設計。MVC設計模式告訴咱們，把應用的模型按必定的規則抽取出來，抽取的層次很重要，這也是判斷開發人員是否優秀的設計依據。抽象與具體不能隔得太遠，也不能太近。MVC並無提供模型的設計方法，而只告訴你應該組織管理這些模型，以便於模型的重構和提升重用性。咱們能夠用對象編程來作比喻，MVC定義了一個頂級類，告訴它的子類你只能作這些，但無法限制你能作這些。這點對編程的開發人員很是重要。 　　業務模型還有一個很重要的模型那就是數據模型。數據模型主要指實體對象的數據 保存（持續化）。好比將一張訂單保存到數據庫，從數據庫獲取訂單。咱們能夠將這個模型單獨列出，全部有關數據庫的操做只限制在該模型中。

 

視圖
　　視圖(View)表明用戶交互界面，對於Web應用來講，能夠歸納爲HTML界面，但有可能爲XHTML、XML和    MVC模式
Applet。隨着應用的複雜性和規模性，界面的處理也變得具備挑戰性。一個應用可能有不少不一樣的視圖，MVC設計模式對於視圖的處理僅限於視圖上數據的採集和處理，以及用戶的請求，而不包括在視圖上的業務流程的處理。業務流程的處理交予模型(Model)處理。好比一個訂單的視圖只接受來自模型的數據並顯示給用戶，以及將用戶界面的輸入數據和請求傳遞給控制和模型。

 

控制
　　控制(Controller)能夠理解爲從用戶接收請求, 將模型與視圖匹配在一塊兒，共同完成用戶的請求。劃分控制層的做用也很明顯，它清楚地告訴你，它就是一個分發器，選擇什麼樣的模型，選擇什麼樣的視圖，能夠完成什麼樣的用戶請求。控制層並不作任何的數據處理。例如，用戶點擊一個鏈接，控制層接受請求後, 並不處理業務信息，它只把用戶的信息傳遞給模型，告訴模型作什麼，選擇符合要求的視圖返回給用戶。所以，一個模型可能對應多個視圖，一個視圖可能對應多個模型。 　　模型、視圖與控制器的分離，使得一個模型能夠具備多個顯示視圖。若是用戶經過某個視圖的控制器改變了模型的數據，全部其它依賴於這些數據的視圖都應反映到這些變化。所以，不管什麼時候發生了何種數據變化，控制器都會將變化通知全部的視圖，致使顯示的更新。這其實是一種模型的變化-傳播機制。模型、視圖、控制器三者之間的關係和各自的主要功能。

 

Java
　　Java 平臺企業版 (J2EE)和其餘的各類框架不同，J2EE爲模型對象(Model Objects)定義了一個規範。 　　視圖(View) 　　在J2EE應用程序中，視圖(View)可能由Java Server Page(JSP)承擔。生成視圖的代碼則多是一個servlet的一部分，特別是在客戶端服務端交互的時候。 　　控制器(Controller) 　　J2EE應用中，控制器多是一個servlet，如今通常用Struts實現。 　　模型(Model) 　　模型則是由一個實體Bean來實現。

Android

對於android，MVC模式簡單的理解能夠當作

一、業務bean

二、美工視圖

三、Activity設計