iOS開發框架-DDA架構學習總結

數據驅動是一種思想，數據驅動型編程是一種編程範式。基於數據驅動的編程，基於事件的編程，以及近幾年業界關注的響應式編程，本質其實都是觀察者模型。數據驅動定義了data和acton之間的關係，傳統的思惟方式是從action開始，一個action到新的action，不一樣的action裏面可能會觸發data的修改。數據驅動則是反其道而行之，以data的變化爲起點，data的變化觸發新的action，action改變data以後再觸發另外一個action。若是data觸發action的邏輯夠健壯，編程的時候就只須要更多的去關注data的變化。思考問題的起點不一樣，效率和產出也不一樣。

Data-Driven-Architecture

 

2.分層架構

咱們將DDA的架構分爲三層：

 

這三層每一層都向下依賴，每一層之間經過面相接口編程的方式產生關聯。

Application Layer

在CDD的討論裏已經詳細的介紹過應用層（Application Layer）的實現方式和數據流向。DDA裏應用層的實現差很少，只不過實現語言換成了Swift。這一層主要由咱們熟悉的UIViewController組成，工做職責包括採集用戶數據和展現UI。採集數據是指數據從Application Layer流向Service Layer，展現UI是指觀察Service Layer流入的數據變化並改變UI。能夠假設這樣一個業務場景來講明Application Layer的工做：用戶在SettingController裏改變本身的用戶名。

數據的流出（採集數據）

用戶在SettingController的輸入框裏輸入新的用戶名，產生newName: String，newName須要傳輸到Server，收到成功回執以後再改變Controller當中的展現。這個完整的流程當中newName就是咱們所關心的業務數據，在newName流向Service Layer以前咱們可能須要進行校驗（名字是否爲空或超過了最大長度），這部分的邏輯更貼近界面的工做，且不涉及任何網絡和DataBase操做，因此能夠放在應用層。若是經過了校驗，下一步就是將newName經過請求告訴Server，全部的網絡和DataBase操做都發生在Service Layer，因此咱們只須要將newName傳輸到Service Layer，到這一步就完成了數據的流出。

數據的流入（改變UI）

Application Layer將newName輸出到Service Layer以後，接下來只須要做爲觀察者監控user: UserProfile這個model當中name property的變化。user model是一個viewModel，使用上和MVVM當中的ViewModel概念一致，ViewModel定義在應用層，但會經過事件觀察者的方式綁定到Service Layer當中的RawModel。ViewModel負責把RawModel當中的數據轉化成View所須要的樣式，View在完成UI的配置以後就不須要維護其它的業務邏輯了。

Service Layer

Servicec Layer負責全部的網絡請求實現，DataBase操做實現，以及一些公用的系統資源使用接口（好比GPS，相冊權限，Push權限等）。對於Application Layer來講Service Layer就像是一個0ms延遲的Server，全部的服務都經過protocol的方式暴露給Application Layer。Service Layer和Data Access Layer（DAL）使用相同的RawModel定義，RawModel定義在DAL，從sqlite當中讀出數據以後就會被立刻轉化成RawModel。RawModel不要和View進行直接綁定，經過ViewModel中轉能夠將數據改變的核心邏輯放在同一的地方管理，調試的時候會頗有用。上面修改用戶名的例子傳入的newName，在這一層經過ModifyUserNameRequest通知Server。ModifyUserNameRequest成功回調以後將user model的name property修改成最新值。name一修改Application Layer對應的View馬上會收到數據改變的事件並展現新的name。Service Layer接下來須要把newName保存到數據庫當中，涉及到和sqlite的交互。全部和sqlite直接打交道的工做都是交給Data Access Layer來作。

Data Access Layer（DAL）

DAL層對下負責和數據庫直接交互，對上經過protocol的方式提供數據操做的接口給Service Layer。數據庫咱們使用sqlite。DAL層不涉及任何具體的業務邏輯，只提供基礎的CRUD接口，這樣一旦DAL層穩定下來，項目中後期出現業務bug基本就能夠省去在DAL層調試。RawModel也定義在DAL，有些項目會在Service Layer和DAL各自定義本身的model，但每多一層model定義，就多了一次轉換和維護的邏輯，對於大部分的項目來講其實沒這個必要。DAL除了提供CRUD以外，還須要搭建線程模型，讀寫要分線程，並且須要同時提供同步異步兩套接口。

這樣初步進行職責劃分後，咱們能夠獲得一個細一點的層次圖。

 

文獻： https://github.com/music4kid/Data-Driven-Architecture-Swift