三層架構是一個非常經典的架構模式，根據系統的職責不同，將系統分成了展現層（主要用來UI展示以及觸發事件源）、業務層（主要用來實現UI事件源觸發的邏輯）、資料訪問層（主要用來進行資料訪問），並配合數模型據進行資料傳遞。三層架構對於大型團隊大型專案的並行開發遠遠不能成為支撐點。故又將三層架構進行細化，分為五層架構。畢竟分層是劃分子系統的必要策略之一。下圖是五層架構模型：

事無鉅細，無論怎麼分層，各個層之間資料解耦始終是首要問題。解耦的目的就是為了降低各個模組的依賴，提高程式碼的可重複利用。下面本文就結合三層架構模式來重點介紹各個層之間的解耦。就用簡單的註冊流程說明下吧。

這裡通過RegisterFragment

結合以上UML模式圖，再加上工廠方法或者依賴管理的框架，就可以實現展現層和業務層的解耦了，我們隨時針對RegisterService和RegisterNotifyService進行替換，這既符合針對介面程式設計，也符合開閉原則，更符合里氏替換。

好，問題來了，我不想更改當前的兩個邏輯，想新增第三個邏輯。是不是得改展現層的類了？其實根本不需要，我們選擇用觀察者模式來解決新新增的邏輯，實現三層架構的真正解耦（這裡主要指展現層和業務層的耦合）。

以下是實現展現層與業務層解耦的思路：

我們把RegisterFragment作為事件源，把註冊的使用者名稱和註冊的密碼作為訊息傳送出去，註冊過的Service可以處理訊息，也就是通過訊息對展現層和業務層進行解耦。以下是改善之後的UML模式圖；

RegisterFragment繼承了BaseEventDispath(抽象類，主要用來進行BaseListener事件分發)，RegisterService和RegisterNotifyService分別繼承了BaseListener介面，成為了監聽者。具體怎麼解耦的呢？

1、BaseEventDispatch抽象類，該抽象類實現了事件源的註冊、取消註冊、通知方法；

2、BaseEventDispatch抽象類的子類RegisterFragment，該類提供了兩個回撥方法;註冊成功和註冊失敗的回撥；

3、BaseListener介面的方法體；

4、實現了BaseListener介面的RegisterService類實現；

5、實現了BaseListener介面的RegisterNotifyService類實現；

到此，我們還需要一個類，把BaseListener類註冊到事件源，事件源也就是展現層，之後就可以發訊息給業務層了，這裡我們暫且把這個類放到展現層。這是當我們再想新增邏輯，只需要實現BaseListener介面，並且修改一下下面這個呼叫方法，把新新增的類註冊到RegisterFragment上就可以了。

以下是呼叫方法及輸出：

至此，展現層與業務層的解耦已講解完畢，需要Demo的童鞋請留下聯絡方式或者關注我的公眾號，IT軟體人，獲取更多技術資訊。