進入正文前吐槽下stroryboard坠敷，最近碰到一個通過StoryBoard在uiviewcontroller上添加UITableView射富，導致自定義Cell中的UILabel無法多行顯示的BUG粥帚，具體什么原因導致的我也說不清了，最終還是通過全代碼添加UITableView規(guī)避了問題芒涡。
最近研究PureMVC架構，覺得對MVC中Model的認識有了點進步弛槐，有必要在這里記錄一下。本文以一個測試項目作為例子來具體介紹下我所理解到的Model層乎串。
這個測試Demo的功能比較簡單速警，主要目標是方便日常工作中的具體測試。
從Demo的界面上我們大致可以想到闷旧，該工程會涉及到Platform/Company/App/Product這樣幾個Model，且每一個具體的Model都有著它自己獨特的數(shù)據(jù)結構匠襟。
業(yè)務與數(shù)據(jù)的耦合
Model是所有業(yè)務邏輯操作的基礎该园，業(yè)務邏輯操作就是在Model數(shù)據(jù)的基礎之上進行各種各樣的運算并得出結果展現(xiàn)在UI界面之上酸舍。MVC架構中里初，一個M能夠對應著各種各樣的V與C，也就是說業(yè)務間可以共享Model淮阐。對于這一點如果不加以有效的約束，M就會暴露在整個工程代碼之中泣特，導致了Model與各種業(yè)務間的強耦合關系挑随，這樣會非常不利于業(yè)務的擴展與遷移。如何實現(xiàn)業(yè)務與Model之間的解耦呢，PureMVC給出的解決方法是Proxy竞阐。
Proxy
一個客戶不想或者不能直接引用一個對 象，此時可以通過一個稱之為“代理”的第三者來實現(xiàn) 間接引用颗搂。代理對象可以在客戶端和目標對象之間起到 中介的作用幕垦，并且可以通過代理對象去掉客戶不能看到 的內(nèi)容和服務或者添加客戶需要的額外服務。
PureMVC通過使用代理來向具體的業(yè)務暴露它們需要的數(shù)據(jù)先改，而代理會保存有Model的引用，這樣就可以取到具體的業(yè)務數(shù)據(jù)了仇奶。因為每一個具體的業(yè)務的關注點各不相同，數(shù)據(jù)的UI展現(xiàn)格式也不一樣岛抄，將數(shù)據(jù)的格式化與轉換操作放置在Proxy中是最合適不過的了狈茉。
通過Proxy這種模式夫椭，業(yè)務就只會與它自已的Proxy打交道并專注于處理自己關心的數(shù)據(jù)氯庆，不同的業(yè)務都與它們各自的Proxy交流數(shù)據(jù)，因此業(yè)務就不在關注底層具體的數(shù)據(jù)結構仁讨，進而解決了數(shù)據(jù)耦合這一問題。
兩個Model
第一個Model當然指的是上面所說的最底層陪竿、最基本的Model屠橄，如Demo中的Platform/Company/App/Product等闰挡。
第二個Model在哪呢？上圖中要選擇平臺的名稱长酗，這個業(yè)務的數(shù)據(jù)我們可以通過Proxy從Platform中取platformName這個字段即可。但僅僅取這一個字段可以滿足需求嗎之拨，如果僅僅做顯示茉继，這一個字段是足夠的蚀乔。但Demo中我們可以看到還有其它業(yè)務，比如根據(jù)具體的平臺獲取平臺下面的公司及公司下面所擁有的應用信息等業(yè)務派撕。這些業(yè)務我們還需要platformId這樣一個字段。也就是說在這個頁面里我們至少需要通過Proxy獲取platformId與platformName這兩個字段终吼，那么獲取到的這樣一個結構在某種意義上不就是一個Model嗎氯哮？只不過這個Model比第一個Model少了很多對業(yè)務沒有意義的其它字段，僅僅只是因為這個業(yè)務而存在蛙粘。
為什么要提出這樣一個概念呢？因為一開始我覺得這樣很繁鎖出牧，因為一個解耦的目標多出了許多Proxy與Model，多出了許多將兩個Model互相轉化的代碼评抚。后來仔細想下，這可能就是程序模塊化所必然要付出的代價吧伯复。
