一、MVC 模式

MVC，即模型-視圖-控制器(Model-View-Model)，是軟件開發(fā)中應用甚廣的一種設計模式。其用意是將數據與視圖分化，利用模型數據控制視圖的顯示，但兩者的交互由控制器控制。在iOS開發(fā)中，MVC模式應用很廣，是iOS控件設計的主要模式之一。

UITableView與UICollectionView 可以說是iOS開發(fā)中最能體現(xiàn)MVC模式的兩種控件，以下舉UITableView為例，其中UITableViewCell是做顯示任務的View，那么每行UITableViewCell都顯示數據源（Datasource）對應的數據，如果把每行顯示的數據封裝成對象，那么我們把它們稱為模型對象（模型數據Model）。

二、模型對象(Model)的封裝

即使不把數據封裝成對象，我們常見的就是字典(NSDictionary)和數組(NSArray)，也能按部就班把數據布局到UITableViewCell上，一定層面上來說也是MVC模式。但為什么不把它封裝成對象呢？有時候，數據的某些字段不能直接布局到View中顯示，特別是遇到復雜的數據結構，這時封裝成對象的好處就體現(xiàn)了，我們可以在對象中處理這些字段后再顯示到View上。封裝成對象，更加利于我們控制業(yè)務處理和編碼，這可是在面向對象編程。

通常我們把數據封裝成對象并不是難事兒，如果每行UITableViewCell顯示的“布局格式”一樣，直接對應把數據布局上去就行，某種意義上來說，UITableViewCell已經事先知道要顯示什么了。比如微信的通訊錄，就顯示頭像和名字，所以UITableViewCell“格式”事先已被確定，壓根就不需要改變自己來適應顯示下一條通訊成員。

但有些時候，每行UITableViewCell顯示的“布局格式”都不一樣，UITableViewCell永遠不知道下一條到底要怎樣布局，比如微博，UITableViewCell不知道下一條微博有沒有轉發(fā)，有沒有圖片，有圖片的話有幾張等等。那這時候應該怎樣布局？

可以觀察到，微博的數據格式是一定的，就是說一條什么都有（轉發(fā)、圖片等）的微博，這時候UITableViewCell中的子控件個數達到飽滿，無論數據要顯示什么，都有子控件可以顯示。但如果有一條微博比如少了圖片，那么要么remove這個顯示圖片的View，要么將這個顯示圖片的View的Frame設為CGRectZero（那么View的布局格式（如果我們把子空間的位置稱為“布局格式”）也是確定的，只是subview的Frame在變）。可想而知只要將缺少的那些字段對應的View的Frame設為CGRectZero即可，不用反復移除添加subview (UITableViewCell 是采取循環(huán)回收利用的)。

這里有個問題，根據上面一段思路，可以自定義UITableViewCell,然后引用一個模型對象并重寫其setter方法，在setter方法中拿到模型對象根據數據計算subview.frame并布局，缺少的字段對應的View.frame直接設為0。但是這樣一來，上拉加載數據的時候需要時間計算Frame，那么界面效果會顯卡，而且當回滾的時候又進行重復的計算工作。這時需要再新建一個模型(姑且稱之為Handler模型)，讓它引用微博模型，然后將對微博模型的處理還有各個subview的frame的計算封裝到Handler模型中，而自定義UITableViewCell則引用Handler模型。那么在加載數據的時候，該模型拿到微博模型數據在setter中即可計算subview.frame，這時UITableViewCell的subview的frame已經準備好，自定義UITableViewCell的模型的setter中直接布局和賦值數據（Handler模型引用著微博模型）

三、視圖（View）的封裝

根據模型對象（Model）的封裝的介紹，遇到復雜的UITableView通常會自定義Cell，把不變的界面因素在初始化創(chuàng)建的時候就可以寫定，動態(tài)的界面因素留給模型去控制。自定義UITableViewCell，讓它引用模型對象并在其setter中布局并賦值，如果subview.frame仍不確定，則再封裝一個Frame模型并引用模型對象，讓自定義Cell引用F模型對象并在setter中布局。

以上兩種布局其實可以看成是一種，即UITableViewCell中的subviews的布局都是一定的了，即使是subview.frame為CGRectZero，但這個subview還必須存在，否則加載的時候會增加開銷。

這里還有另外一種App常見的界面布局，即類似微信收藏的布局，每個UITableViewCell都屬于一個類型，有圖片、視頻、文檔等等，我嘗試按照處理微博的方法來解決問題，但效果不如意。微信收藏這種布局參雜很多種類型，每個UITableViewCell只顯示一種類型數據，顯示了一種數據則一定不會有其它類型數據，如果按照微博數據處理方式處理，則在frame賦值的時候有一大串判斷和CGRectZero,每每增加一種類型，就要修改源文件增加判斷，處理要特別全面否則容易出現(xiàn)bug。嘗試處理方法是自定義各種類型的UITableViewCell對應各種類型數據，給每種類型的UITableViewCell給定不同的Identifier。這樣，圖片只會被布局到圖片Cell，文檔只會被布局到文檔Cell。

總結

以上是生活随笔為你收集整理的(iOS开发总结)MVC模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。