iOS理論知識:MVC設計模式,ios理論mvc設計模式
在iOS開發過程中,使用最多、頻繁的設計模式之一應該就是MVC設計模式。MVC的全名是Model View Controller,是資料模型(model)-視圖(view)-控制器(controller)的縮寫,一種軟體設計典範,用一種商務邏輯、資料、介面顯示分離的方法組織代碼,將商務邏輯聚集到一個組件裡面,在改進和個人化定製介面及使用者互動的同時,不需要重新編寫商務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化使用者介面的結構中。
一、MVC簡介
MVC開始的時候是存在於傳統型程式中的,M是指業務資料模型,V是指使用者介面視圖,C則是控制器,使用MVC的目的是將M和V的實現代碼分離,從而使同一個程式可以使用不同的表現形式。比如一批統計資料可以分別用柱狀圖、餅圖、折線圖來表示。C存在的目的則是確保M和V的同步,一旦M改變,V應該同步更新。
模型-視圖-控制器(MVC)是Xerox PARC在二十世紀八十年代為程式設計語言Smalltalk-80發明的一種軟體設計模式,後已經被廣泛使用。後來被推薦為Oracle旗下Sun公司Java EE平台的設計模式,並且受到越來越多的使用ColdFusion和PHP的開發人員的歡迎。模型-視圖-控制器模式是一個有用的工具箱,它有很多好處,但也有一些缺點。
二、MVC模式
MVC 是一種使用 MVC(Model View Controller 模型-視圖-控制器)設計建立 Web 應用程式的模式:
Model(模型)表示程式的核心(比如資料庫記錄列表)。View(視圖)顯示資料(資料庫記錄)。Controller(控制器)處理輸入(寫入資料庫記錄)。
MVC 模式同時提供了對 HTML、CSS 和 JavaScript 的完全控制。
Model(模型)是程式中用於處理應用程式資料邏輯的部分,通常模型對象負責在資料庫中存取資料。
View(視圖)是程式中處理資料顯示的部分,通常視圖是依據模型資料建立的。
Controller(控制器)是程式中處理使用者互動的部分,通常控制器負責從視圖讀取資料,控制使用者輸入,並向模型發送資料。
MVC 分層有助於管理複雜的程式,因為您可以在某段個時間內專門關注其中的一個方面。例如,您可以在不考慮商務邏輯的情況下只專註於視圖的設計,這樣也讓應用程式的測試更加容易。
MVC 分層同時也簡化了分組開發。不同的開發人員可同時開發視圖、控制器邏輯和商務邏輯,方便多人合作開發。
三、MVC架構
MVC指MVC模式的某種架構,它強制性的使應用程式的輸入、處理和輸出分開。使用MVC應用程式被分成三個核心組件:模型、視圖、控制器。它們各自處理自己的任務。最典型的MVC就是JSP + servlet + javabean的模式。
1.模型:
模型表示企業的資料和商務規則。在MVC的三個組件中,模型擁有最多的處理任務。例如它可能用像EJBs和ColdFusion Components這樣的構件對象來處理資料庫,被模型返回的資料是中立的,就是說模型與資料格式無關,這樣一個模型能為多個視圖提供資料,由於應用於模型的代碼只需寫一次就可以被多個視圖重用,所以減少了代碼的重複性。
2.視圖:
視圖是使用者能看到的並與之互動的介面。對於較老式的Web應用程式來說,視圖就是由HTML元素組成的介面,在新式的Web應用程式中,HTML依舊在視圖中扮演著重要的角色,但一些新的技術層出不窮,它們包括Adobe Flash和像XHTML,XML/XSL,WML等一些標識語言和Web services。MVC好處是它能為應用程式處理很多不同的視圖。在視圖中其實沒有真正的處理髮生,不管這些資料是聯機儲存的還是一個僱員列表,作為視圖來講,它只是作為一種輸出資料並允許使用者操縱的方式。
3.控制器:
控制器接受使用者的輸入並調用模型和視圖去完成使用者的需求,所以當單擊Web頁面中的超連結和發送HTML表單時,控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求,然後再確定用哪個視圖來顯示返回的資料。
四、架構模式和設計模式的區別
好多程式員往往會把架構模式和設計模式混淆,認為MVC是一種設計模式。實際上它們完全是不同的概念。架構、設計模式這兩個概念總容易被混淆,其實它們之間還是有區別的。架構通常是代碼重用,而設計模式是設計重用,架構則介於兩者之間,部分代碼重用,部分設計重用,有時分析也可重用。在軟體生產中有三種層級的重用:內部重用,即在同一應用中能公用使用的抽象塊;代碼重用,即將通用模組組合成庫或工具集,以便在多個應用和領域都能使用;應用程式框架的重用,即為專用領域提供通用的或現成的基礎結構,以獲得最進階別的重用性。
架構與設計模式雖然相似,但卻有著根本性的不同。設計模式是對在某種環境中反覆出現的問題以及解決該問題的方案的描述,它比架構更抽象;架構可以用代碼錶示,也能直接執行或複用,而對模式而言,只有執行個體才能用代碼錶示;設計模式是比架構更小的元素,一個架構中往往含有一個或多個設計模式,架構總是針對某一特定應用領域,但同一模式卻可適用於各種應用。可以說,架構是軟體,而設計模式是軟體的知識。
架構模式有:MVC、MTV、MVP、CBD、ORM等等;
架構有:C++語言的QT、MFC、gtk,Java語言的SSH 、SSI,php語言的 smarty(MVC模式),python語言的django(MTV模式)等等
設計模式有:單例模式、原廠模式、適配器模式、策略模式等等
總之,架構是大架構,用來對軟體設計進行分工;設計模式是小模式,對具體問題提出解決方案,以提高代碼複用率,降低耦合度,也就是經常說的高內聚低耦合。
五、MVC特點
(一)優點:
1.低耦合性
視圖層和業務層分離,這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼,同樣,一個應用的商務程序或者商務規則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離,所以很容易改變應用程式的資料層和商務規則。
模型是自包含的,並且與控制器和視圖相分離,所以很容易改變應用程式的資料層和商務規則。如果把資料庫從MySQL移植到Oracle,或者改變基於RDBMS資料來源到LDAP,只需改變模型即可。一旦正確的實現了模型,不管資料來自資料庫或是LDAP伺服器,視圖將會正確的顯示它們。由於運用MVC的應用程式的三個組件是相互獨立,改變其中一個不會影響其它兩個,所以依據這種設計思想能構造良好的松耦合的構件。
2.高重用性
隨著技術的不斷進步,需要用越來越多的方式來訪問應用程式。MVC模式允許使用各種不同樣式的視圖來訪問同一個伺服器端的代碼,因為多個視圖能共用一個模型,它包括任何WEB(HTTP)瀏覽器或者無線瀏覽器(wap),比如,使用者可以通過電腦也可通過手機來訂購某樣產品,雖然訂購的方式不一樣,但處理訂購產品的方式是一樣的。由於模型返回的資料沒有進行格式化,所以同樣的構件能被不同的介面使用。例如,很多資料可能用HTML來表示,但是也有可能用WAP來表示,而這些表示所需要的命令是改變視圖層的實現方式,而控制層和模型層無需做任何改變。由於已經將資料和商務規則從展示層分開,所以可以最大化的重用代碼了。模型也有狀態管理和資料持久性處理的功能,例如,基於會話的購物車和電子商務過程也能被Flash網站或者無線連網的應用程式所重用。
3.生命週期成本低
MVC使開發和維護使用者介面的技術含量降低。
4.部署快
使用MVC模式使開發時間得到相當大的縮減,它使程式員(Java開發人員)集中精力於商務邏輯,介面程式員(HTML和JSP開發人員)集中精力於表現形式上。
5.可維護性高
分離視圖層和商務邏輯層也使得WEB應用更易於維護和修改。
6.有利軟體工程化管理
由於不同的層各司其職,每一層不同的應用具有某些相同的特徵,有利於通過工程化、工具化管理程式碼。控制器也提供了一個好處,就是可以使用控制器來聯結不同的模型和視圖去完成使用者的需求,這樣控制器可以為構造應用程式提供強有力的手段。給定一些可重用的模型和視圖,控制器可以根據使用者的需求選擇模型進行處理,然後選擇視圖將處理結果顯示給使用者。 (二)缺點:
1.沒有明確的定義
完全理解MVC並不是很容易。使用MVC需要精心的計劃,由於它的內部原理比較複雜,所以需要花費一些時間去思考。同時由於模型和視圖要嚴格的分離,這樣也給調試應用程式帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。
2.不適合小型,中等規模的應用程式
花費大量時間將MVC應用到規模並不是很大的應用程式通常會得不償失。
3.增加系統結構和實現的複雜性
對於簡單的介面,嚴格遵循MVC,使模型、視圖與控制器分離,會增加結構的複雜性,並可能產生過多的更新操作,降低運行效率。
4.視圖與控制器間的過於緊密的串連
視圖與控制器是相互分離,但卻是聯絡緊密的組件,視圖沒有控制器的存在,其應用是很有限的,反之亦然,這樣就妨礙了他們的獨立重用。
5.視圖對模型資料的低效率訪問
依據模型操作介面的不同,視圖可能需要多次調用才能獲得足夠的顯示資料。對未變化資料的不必要的頻繁訪問,也將損害操作效能。
6.一般進階的介面工具或構造器不支援模式
改造這些工具以適應MVC需要和建立分離的組件的代價是很高的,會造成MVC使用的困難