文章轉載自： Sindri的小巢 原文鏈接：http://www.jianshu.com/p/2b2290fa0beb

前言

去model化是一種框架設計上的做法，其中的model并不是指架構中的model層，套用Casa大神博客中的原文就是：

model化就是使用數據對象，去model化就是不使用數據對象。

常見的去model化做法是使用字典保存數據信息，然后提供一個reformer負責將這些字典數據轉換成View層可展示的信息，其流程圖如下：

更詳細的理論知識可以看Casa大神的去model化和數據對象。本文基于Casa大神的實踐基礎使用另外一種去model化的實現方式。

使用背景

在很早之前就看過大神的文章，不過一直沒有去嘗試這種做法。在筆者最近跳入新坑之后，總算是有了這么一次機會。需求是存在著三個非常相似的cell，但分別對應著不同的數據model：

總結三個cell都需要的展示數據包括： * 產品名稱 * 使用條件 * 截止日期 * 背景圖片*

此外，優惠信息屬于第一個和第二個獨有的。現在這一需求存在的問題主要有這么三點：

三種數據對象在服務器返回的屬性字段中命名差別大

這是大部分的應用都存在的一個問題，但是本文中的數據對象有一個顯著的特點是它們對應顯示的cell存在很大的相似度，可以被轉換成相似的展示數據

三種cell可以封裝成一種，卻分別對應著不同的數據對象

這里涉及cell和數據對象的對接問題，如果cell在以后發生改變了，那么原有的數據對象是否還能適用

控制器需要在數據源方法中調配不同的cell和model，耦合過大

這個也是常見的問題之一，通常可以考慮適用工廠模式將調配的業務分離出去，但在本文中采用去model的方式實現

這些問題都有可能導致項目后期維護的過程中變得難以修改，小小的需求改動都會導致代碼的大改。筆者的解決方式是制定cell和model之間對應的兩個協議，從而控制器無需理會兩者的具體類型。

實現

我在上一篇文章MVC架構雜談中提到過M層的業務邏輯放在model中，雖然本文要去model化，但只是去除屬性對象，自身的邏輯處理還保留著。下面是筆者去model化的協議圖以及協議聲明屬性：

對于本文之中這種存在共同顯示效果的model，可以聲明一個包含多個readonly屬性的協議，讓這些模型對象在協議的getter方法中執行數據->展示這一過程的業務邏輯，而model自身只需簡單的持有字典數據即可：

以LXDCouponTicketModel為例，協議的實現代碼如下：

通過讓三個數據對象實現這個協議，筆者將要展示的數據結果進行統一。在這種情況下，封裝成單個的cell也無需關心model的具體類型是什么，只需實現針對單元格配置的協議方法獲取展示的數據即可：

三個問題前兩個已經解決了：通過協議統一數據對象的展示效果，這時候并不需要model保存多個屬性對象，只需要在適當的時候直接從字典中獲取數據并執行數據可視化這一邏輯即可。cell也不會受限于傳入的參數類型，只需要簡單的調用協議方法獲取需要的數據即可。那么最后一個控制器的協調問題就變得簡單了：

當cell和model共同通過協議的方式實現交流的時候，控制器存儲的數據源也就可以不關心這些對象的具體類型了。通過泛型聲明多個數據源，控制器此時的職責僅僅是根據狀態機的改變決定使用哪個數據源來展示而已。當然，雖然筆者統一了這三個數據源的類型，但是歸根到底總要根據服務器返回的json創建不同的數據對象存放到這些數據源中。如果把這個業務放在控制器中原本就達不到松耦合的作用，因此引入一個中間人Helper來完成這個業務：

去model化之后整個項目的業務流程大致可以用下圖表示：

這種方式最大的好處在于控制器和視圖不再依賴于model的具體類型，這樣在服務器返回的json中修改了模型對象字段的時候，修改ModelProtocol的對應實現即可。甚至在以后的版本再添加現金券各種其他票券的時候，只需要在Helper這一環節添加相應的工廠即可完成改動

尾言

去model化是一種有效快捷的松耦合方式，但絕不是萬能藥。在本文的demo中不難看到筆者使用這一方式最大的原因在于多個cell之間有太多的共性而model的屬性字段全不相同。另一方面在這種設計中Helper可能會因為模型對象的增加變得臃腫，需要謹慎使用。一個好的項目框架總是隨著需求改變在不斷的調整的，沒有絕對最佳的設計方案。但是嘗試使用不同的思路去搭建項目可以提升我們的認知，培養對于開發框架設計的認識。