結構設計的層次是否越多越好？

多人都會說，凡事不能走極端，走了極端就過猶不及。所以應該分層，但不能過分分層，應該視具體情況來定。這樣的話聽起來很有道理，卻只是一句廢話。當我們遇到問題時，還是摸不著頭腦！

看看知名的架構師是怎麼說的吧！來自蔡學鏞

我做（開發）架構的幾個原則，根據優先次序高低排列：1. （邏輯）拆分越細越好 2. 依賴關細越少越好 3. 互動越少越好 ... 相互矛盾時，如果沒有特殊理由，以優先權高者勝出。

由此啟發，我覺得設計架構應該拆的越細越好。這樣做有如下幾點好處：

• 對於大中型軟體，層次越多，每一層就更單純，更容易維護。
• 團隊成員只需瞭解一小部分業務，就能順利進行開發。
• 相對底層的模組，可以更好的重用。
• 層次分的越多，開發者對抽象的理解就更深入。

iOS說到分層，有幾種常見的做法。

• 按功能分：有MVC，MVVM......
• 按層次分：有資料層、邏輯層、展現層......

這些分層看起來五花八門，但實質並不衝突。最近讀了一篇文章，深受啟發，在其模式的基礎上修改了一個自己的架構模式，暫且稱之為VPBD。廢話不多說，線上架構圖：

下面說說各個模組分別幹了什麼？

• ViewController(View)：管理View的層次結構、生命週期、一些組合過的View。
• ViewModel：負責轉換View需要的資料格式。
• Presenter：顯示View、ViewController的邏輯。
• Router(Wireframe)：頁面跳轉邏輯。
• Business：核心業務邏輯，複用性很高。
• Model：基本資料模型，根據業務來定義。
• DataSource：對於資料的抽象，對於Business層而言，不需要知道它是從網路、資料庫還是快取中得到的。

講模式不能光說不練，所以我決定寫一個Demo來實踐這一模式。

國慶過來加了3天班，總算寫了一個Demo，因為基於目前公司產品的後臺，所以程式碼就不貼了。講講思路就好。

最終的版本比上面圖中，做了一些妥協，主要是把Presenter和Router拿掉了。因為目前的專案互動都比較簡單，而Presenter和Router都是處理互動相關程式碼的，所以即使寫出來程式碼也很少。下面是結構圖：

更詳細的結構圖：

在最早的程式碼中，ViewController、Business、ViewModel都是寫在ViewController裡面的，這樣遲早是要把ViewController寫爆的。為了i面ViewController複雜化，我就把它拆成了3個部分。

ViewController

負責View生命週期的管理、檢視跳轉、以及使用者事件的接收。

Business

負責所有的業務邏輯，它不需要知道View是怎樣的。View需要的資料結構會通過ViewModel來定義，所以Business就是處理邏輯，並把最終資料轉換成ViewModel，拋給ViewController即可。這個過程中轉換成ViewModel比較簡單，最核心的是定義業務邏輯。即這個模組是幹嘛的。舉個例子：

@interface HJShopModule : NSObject

@property (nonatomic,strong) HJShopQueryConfig* queryConfig;

@property (nonatomic,copy) NSString* currentShopId;

- (void)getShopListOnSuccess:(ResponseArray)successBlock
                   onFailure:(ResponseString)failureBlock;

- (void)getShopDetailOnSuccess:(ResponseObject)successBlock
                     onFailure:(ResponseString)failureBlock;

@end

上面定義的是一個商店模組，就是商店相關的任何邏輯都應該在這裡。一個商店模組能幹嘛？這需要從需求出發。

• 需求1：通過篩選得到商店列表
• 需求2：檢視商店詳情

根據以上兩個需求，我先把篩選條件封裝成一個物件（篩選條件多且複雜），然後呼叫getShopList方法，該方法會篩選條件解析出來，並向後臺請求，請求成功再將資料封裝好，丟給ViewController。同理，檢視商店詳情，同樣只需要呼叫一個介面。這裡雖然只寫了兩個，但是真實情況會有很多介面，比如收藏商店、分享商店......業務需求有多少，這裡就要加多少。因為寫在這裡的方法都差不多，所以可讀性、維護性都會比較好。

ViewModel

我這裡的ViewModel和MVVM中的ViewModel不太一樣。我這裡的ViewModel其實是Model的延伸。我們定義Model的時候是根據業務來定的。而ViewModel是根據View的展示需求來定的。兩者只是結構上的不同，並沒有本質差異。假如ViewModel會增加一些類，但是ViewController就不用再做繁瑣無聊的資料轉換了。

總結

用了這個模式，ViewController得到了很大的簡化，但是以後可能還會有複雜化的問題。尤其是當頁面的互動邏輯變得複雜的時候。這時候需要把互動再抽象出來，就像最上面的一張圖。但目前我覺得這是沒有必要的。