MVC設計模式
模型-視圖-控制器（Model-View-Controller，MVC）,是Xerox PARC在20世紀80年代為編程語言Smalltalk－80發(fā)明的一種軟件設計模式，至今已廣泛應用于用戶交互應用程序中。在iOS開發(fā)中MVC的機制被使用的淋漓盡致，充分理解iOS的MVC模式，有助于我們程序的組織合理性。
1.模型對象(Model層)
模型對象封裝了應用程序的數(shù)據(jù)，并定義操控和處理該數(shù)據(jù)的邏輯和運算。例如，模型對象可能是表示游戲中的角色或地址簿中的聯(lián)系人。用戶在視圖層中所進行的創(chuàng)建或修改數(shù)據(jù)的操作，通過控制器對象傳達出去，最終會創(chuàng)建或更新模型對象。模型對象更改時（例如通過網(wǎng)絡連接接收到新數(shù)據(jù)），它通知控制器對象，控制器對象更新相應的視圖對象。
簡單來理解就是后臺數(shù)據(jù)庫與app之間的交流，前端變化后臺會跟著變化 實現(xiàn)數(shù)據(jù)庫的增刪改查
（1）創(chuàng)建數(shù)據(jù)庫、創(chuàng)建相應的表
（2）完成針對數(shù)據(jù)庫各個表的增、刪、改、查的操作類
（3）映射數(shù)據(jù)庫各個表的實體類（這個實體類的作用就是溝通數(shù)據(jù)庫層（M）和控制層（C）的橋梁，同時這個實體類也將擔負其后臺數(shù)據(jù)（xml、sbjson等）與本地數(shù)據(jù)的溝通和存儲）
本層要實現(xiàn)的功能：
?。?）
本層輸入件：sql增加或插入數(shù)據(jù)庫表對應的實體類的對象的語句
本層輸出件：增加、或插入數(shù)據(jù)庫
?。?）
本層輸入件：sql查詢語句
本層輸出件：返回存儲實體類對象的數(shù)組
（3）
本層輸入件：sql刪除語句
本層輸出件：刪除數(shù)據(jù)庫中的指定信息
2.視圖對象（View層）（storyboard和xib或者在.m中寫）
視圖對象是應用程序中用戶可以看見的對象。視圖對象知道如何將自己繪制出來，并可能對用戶的操作作出響應。視圖對象的主要目的，就是顯示來自應用程序模型對象的數(shù)據(jù)，并使該數(shù)據(jù)可被編輯。盡管如此，在 MVC 應用程序中，視圖對象通常與模型對象分離。
在iOS應用程序開發(fā)中，所有的控件、窗口等都繼承自 UIView，對應MVC中的V。UIView及其子類主要負責UI的實現(xiàn)，而UIView所產(chǎn)生的事件都可以采用委托的方式，交給UIViewController實現(xiàn)。
本層實現(xiàn)的功能就是控件的布局。
3.控制器對象（controller 就是.m文件）
在應用程序的一個或多個視圖對象和一個或多個模型對象之間，控制器對象充當媒介?？刂破鲗ο笠虼耸峭焦艿莱绦?，通過它，視圖對象了解模型對象的更改，反之亦然。控制器對象還可以為應用程序執(zhí)行設置和協(xié)調(diào)任務，并管理其他對象的生命周期。
控制器對象解釋在視圖對象中進行的用戶操作，并將新的或更改過的數(shù)據(jù)傳達給模型對象。模型對象更改時，一個控制器對象會將新的模型數(shù)據(jù)傳達給視圖對象，以便視圖對象可以顯示它。
主要作用
本層輸入件：界面控件中數(shù)據(jù)和事件
本層輸出件：
第一：調(diào)用M層的接口，更新M層（數(shù)據(jù)庫）中的數(shù)據(jù)
第二：調(diào)用V層的接口，更新V層（界面）中的數(shù)據(jù)
對于不同的UIView，有相應的UIViewController，對應MVC中的C。例如在iOS上常用的UITableView，它所對應的Controller就是UITableViewController。
1.Model和View永遠不能相互通信，只能通過Controller傳遞。
2.Controller可以直接與Model對話（讀寫調(diào)用Model），Model通過Notification和KVO機制與Controller間接通信。
3.Controller可以直接與View對話，通過outlet,直接操作View,outlet直接對應到View中的控件,View通過action向Controller報告事件的發(fā)生(如用戶Touch我了)。Controller是View的直接數(shù)據(jù)源（數(shù)據(jù)很可能是Controller從Model中取得并經(jīng)過加工了）。Controller是View的代理（delegate),以同步View與Controller。
利用MVC思想組織的文件結構一例：
＊＊當然，軟件中還有如下的幾種代碼＊＊
現(xiàn)實中，工程中還有以下幾種類型的代碼：
（1）接口文件［數(shù)據(jù)操作］
?。?）解析通過接口獲取的數(shù)據(jù)［數(shù)據(jù)操作］
（3）開源框架（實現(xiàn)各種界面效果、解析各種數(shù)據(jù)）［數(shù)據(jù)操作＋V顯示］
?。?）工具類（比如為圖片增加圓角、實現(xiàn)checkbox、實現(xiàn)各種頁面效果、數(shù)據(jù)加密解密）[數(shù)據(jù)操作＋V顯示]
?。?）本項目提煉的公用類（如驗證、升級檢測、數(shù)據(jù)更新等）［數(shù)據(jù)操作M］
所以還是需要自己去總結精煉自己的項目的（文件千萬別瞎放，后來看可惡心了。。。說多了都是淚。。。）
有關”模型－視圖－控制器”的完整信息，請參閱 Concepts in Objective-C Programming（Objective-C 編程中的概念）中的：Model-View-Controller
KVO模式
KVO,即：Key-Value Observing，它提供一種機制，當指定的對象的屬性被修改后，則對象就會接受到通知。簡單的說就是每次指定的被觀察的對象的屬性被修改后，KVO就會自動通知相應的觀察者了。
KVO其實也是“觀察者”設計模式的一種應用。我的看法是，這種模式有利于兩個類間的解耦合，尤其是對于 業(yè)務邏輯與視圖控制 這兩個功能的解耦合。
KVO這一機制是基于NSKeyValueObserving協(xié)議的，Cocoa通過這個協(xié)議為所有遵循協(xié)議的對象提供了自動觀察屬性變化的能力。在NSObject中已經(jīng)為我們實現(xiàn)了這一協(xié)議，所以我們不必去實現(xiàn)這個協(xié)議。
為什么要使用KVO？
有的朋友可能會有疑問，為什么要使用KVO呢？KVO能實現(xiàn)的我使用Setter方法同樣能實現(xiàn)啊。其實不然KVO存在還是有它的價值的，那么接下來我們細數(shù)一下KVO的獨特價值吧：
1.我們創(chuàng)建一兩個setter方法感覺沒什么，但是如果要觀察的屬性非常多，那么還能一一重寫setter方法來實現(xiàn)嗎？想必大家心里已有了答案，但是利用KVO則能很好的解決上述問題。
2.我們自定義的類是很容易改寫setter方法的，但是如果你是用一個已經(jīng)編譯好了的類庫時要監(jiān)控其中一個屬性時怎么辦？難道還要去重寫setter方法？如果使用KVO則很輕松解決問題。
3.使用KVO能夠方便的記錄變化前的值和變化后的值，不適用KVO你還要自己來解決這些問題。
4.KVO讓你的代碼看起來更加簡潔清晰易于維護。
如何使用KVO呢？
首先，你要為你想觀察的對象添加一個觀察者代碼如下：
[object addObserver: observer forKeyPath: @"frame" options: 0 context: nil];
調(diào)用方法是:
object : 被觀察對象
observer: 觀察對象
forKeyPath里面帶上property的name，如UIView的frame、center等等
options: 有4個值，分別是：
NSKeyValueObservingOptionNew 把更改之前的值提供給處理方法
NSKeyValueObservingOptionOld 把更改之后的值提供給處理方法
NSKeyValueObservingOptionInitial 把初始化的值提供給處理方法，一旦注冊，立馬就會調(diào)用一次。通常它會帶有新值，而不會帶有舊值。
NSKeyValueObservingOptionPrior 分2次調(diào)用。在值改變之前和值改變之后。
注：例子里的0就代表不帶任何參數(shù)進去
context: 可以帶入一些參數(shù)，任何類型都可以，強制轉(zhuǎn)就可以。
接下來觀察到值的變化后該應該調(diào)用相關的方法來處理，這個方法是：
－ (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
其中：
keyPath: 對應forKeyPath
object: 被觀察的對象
change: 對應options里的NSKeyValueObservingOptionNew、NSKeyValueObservingOptionOld等
context： 對應context
通過滑動slider來改變相關的值，相關的只發(fā)生變化后從而改變標簽的顏色。
下載地址：https://github.com/zhaishuai/KVOPractice
代碼來自zhai shuai
KVC模式
KVC的基本概念
Key-value coding,它是一種使用字符串標識符，間接訪問對象屬性的機制,而不是直接調(diào)用getter 和 setter方法。通常我們使用valueForKey 來替代getter 方法，setValue:forKey來代替setter方法。
下面是使用KVC 和 不使用 KVC的代碼對比
Persion *persion = [ [Persion alloc] init ];
//不使用
KVCpersion.name = @"hufeng" ;
//使用KVC的寫法
[persion setValue:@"hufeng" forKey:@"name"];
看出區(qū)別來了嗎？你可能會說 你寫的太簡單了，我們實際用的時候不可能有這樣復雜的類，下面我們寫個復雜點的：我們有一個人 這個人有一個手機類 這個手機類 有一個電池類 我們要獲取這個電池類 比之前復雜了吧。
沒有KVC
Persion *persion = [ [Persion alloc] init ];
Phone *phone = persion.phone;
Battery *battery = phone.battery;
使用KVC
Battery *battery = [persion valueForKeyPath: @"phone.battery" ];
注意- valueForKeyPath 里面的值是區(qū)分大小寫的，你如果寫出Phone.Battery 是不行的
說到這里你可能會問 我能不能對 NSArray 調(diào)用KVC嗎？ 答案是否定的，因為array 沒有keys啊，但是你可以對array里面的item 使用KVC。
KVC 最常用的還是在序列化和反序列話對象。我們經(jīng)常需要把json字符串反序列化成我們想要的對象 下面是一個例子 將字典用NSKeyedArchiver 序列化成對象
-(id)initWithDictionary:(NSDictionary *)dictionary {
self = [self init];
if (self){
[self setValuesForKeysWithDictionary:dictionary];
}
return self
}
主要是讓大家多了解一點
單例模式
單例模式是一種常用的軟件設計模式。在它的核心結構中只包含一個被稱為單例的特殊類。通過單例模式可以保證系統(tǒng)中一個類只有一個實例而且該實例易于外界訪問，從而方便對實例個數(shù)的控制并節(jié)約系統(tǒng)資源。如果希望在系統(tǒng)中某個類的對象只能存在一個，單例模式是最好的解決方案。
顧名思義，單例，即是在整個項目中，這個類的對象只能被初始化一次。它的這種特性，可以廣泛應用于某些需要全局共享的資源中，比如管理類，引擎類，也可以通過單例來實現(xiàn)傳值。UIApplication、NSUserDefaults等都是IOS中的系統(tǒng)單例。
“單例模式”是我在iOS中最常使用的設計模式之一。單例模式不需要傳遞任何參數(shù)，就有效地解決了不同代碼間的數(shù)據(jù)共享問題。
iOS中的單例模式應用
iOS中好幾個類都是采用了單例模式，比如NSApplication， NSFontManager, NSDocumentController,NSHelpManager, NSNull,NSProcessInfo, NSScriptExecutionContext, NSUserDefaults.
關于單例的寫法，因為我上網(wǎng)看了好多種都和我看的不太一樣寫的，所以我就不貼了，想看的可以去我的另一篇文章里有單例在數(shù)組前面
寫的不好請見諒，好多文章歸攏的東西不太會用。。。還需要學習
