移動App架構設計
本文主要總結了幾種常用的架構模式, 基本是層層遞進的轉載請註名出處 http://blog.csdn.net/uxyheaven, 良好的排版在https://github.com/uxyheaven/閱讀
如果覺得本文不錯, 請在csdn給個頂, github給個star.
Native app的開發相比傳統的項目迭代週期要短很多, 需求的變化也頻繁一些, 在開發的不同生命週期裏採用不同的架構模式可以有效的節約開發時間, 提高開發效率, 這篇文章介紹幾種常用的架構模式:
表現層
基本的MVC
移動app一般都是採用經典的mvc框架
| 層次 | 作用 | 設計原則 |
|---|---|---|
| 模型層(model) | 封裝了應用的一系列數據, 並定義了操作, 處理這些數據的邏輯和計算規則。 | 通過Notification,KVO對控制器進行反饋 |
| 視圖層(view) | 視圖對象是一個應用中, 用戶可以看到的對象. 視圖對象知道如何繪製自己, 也能夠響應用戶的操作. 視圖對象的主要目的之一是將應用模型對象中的數據顯示出來, 並允許用戶編輯該數據 | 視圖通過不能直接操作模型層, 通過target-action, delegate, dataSource和控制器進行反饋 |
| 控制器層(controller) | 控制器層是在視圖層和若干個模型層的中間人 | c可以直接操作模型層和視圖層 |
總結:C對M：APIC對V：OutletV對C：Target-action， Delegate，DatasourceM對C：Notification，KVO
MVC的改進版 MVVM
MVVM是在MVC的基礎上多了一個View Model: 表示邏輯, 將 model 的數據轉換爲 view 可以呈現的東西. 適合大量展示類的App
HMVC
Hierarchical MVC, 把客戶端應用程序分解爲有層次的父子關係的MVC, 反覆應用這個模式, 形成結構化的客戶端架構. 適合重型B/S架構的WebApp.
一個MVC模塊由應用程序的一個模塊抽象而成. 其中很重要的一個概念就是 Parent MVC , 它可以對應界面上的實體, 也可以是一個抽象的對象. 設想一個app 有標籤欄, 工具欄, 導航欄, 主工作區, 對應到HMVC上就是這個app最底部的標籤欄 是 Layer1, Layer2 導航欄,主要工作區, 工具欄. 如果覺得 Layer2 太複雜可以吧主要工作區放到 Layer3, 依次類推.
Controller 是功能模塊的總控室, 它負責和子Controller或父Controller通信，並通知它的 View 處理改變界面顯示, Model 處理一些業務邏輯或數據庫訪問操作. 如才的例子裏, 點擊了工具欄裏的一個按鈕, 工具欄的Controller 響應這個event, 發現是要切換主工作區, 工具欄做不了,就傳遞他的父Controller處理(如果父Controller也處理不了, 就繼續往上傳遞)然後標籤欄的Controller處理切換主工作區.
優點:
- 把程序分成了幾個部分, 降低了依賴性
- 支持鼓勵重用代碼, 組件或者模塊。
- 在今後的維護中, 提高了可擴展性。
分層設計
三層架構
我們在來看一下經典的三層架構
從上至下爲
- 表示層(UI)
- 業務邏輯層或稱爲領域層(BLL)
- 數據訪問層(DAL)
| 層次 | 作用 | 設計原則 |
|---|---|---|
| 表示層(UI) | 向用戶展現特定業務數據，採集用戶的輸入信息和操作 | 用戶至上，兼顧簡潔；不包含任何業務相關的邏輯處理 |
| 業務邏輯層(BLL) | 從ＤＡＬ中獲取數據, 在ＵＩ顯示; 從ＵＩ中獲取用戶指令和數據, 執行業務邏輯或通過ＤＡＬ寫入數據源 | 作爲U層與Ｄ層的橋樑,目的在於展現清晰的函數結構, 只負責數據處理傳遞, 不涉及ＳＱＬ語句和ＡＤＯ.ＮＥＴ |
| 數據訪問層(DAL) | 直接操作數據庫，針對數據的增添 刪除 修改 查找; 具體爲業務邏輯層或表示層提供數據服務。 | 專門操作數據庫, 不考慮數據合法性. 數據庫錯誤返回－1, 邏輯錯誤返回0, 並告知錯誤原因, 成功返回1 |
然後呢,我們現在的架構則是
四層架構
在三層架構的基礎上多了業務規則層, 通常的三層是把業務邏輯和業務規則合併爲一個層，統稱爲業務層.業務規則層的提出,既可以及時處理用戶輸入的不合法信息, 又可以及時處理數據庫錯誤, 增大了業務邏輯層的結構清晰度, 讓業務邏輯人員專心致志做邏輯
從上至下爲
- 表示層
- 業務規則層
- 業務邏輯層或稱爲領域層
- 數據訪問層
| 層次 | 作用 | 設計原則 |
|---|---|---|
| 業務規則層(ECL) | 對於UI層傳下來的參數來說，檢查合法性。 | 用戶至上，兼顧簡潔；不包含任何業務相關的邏輯處理 |
引入service層
引入service層的架構和普通的分層架構的不同是: service層內部有數據, 可以單獨運行.
從上至下爲
- 表現層
- 服務層(service)
- 數據訪問層
- 業務邏輯層
| 層次 | 作用 | 設計原則 |
|---|---|---|
| 表現層 | 顯示與用戶的互交 | |
| 服務層 | service層提供表現層的業務邏輯入口,通過定義接口服務的形式,通過接口調用來完成. | |
| 業務邏輯層 | 1接收服務層傳來的DTO, 然後根據業務規則, 對傳入的DTO進行加工, 返回加工後的信息 2 需要爲每個對象提供業務行爲, 並且這些對象之間是獨立的 3 業務對象之間的交互流程通過服務層來組織 | |
| 數據訪問層 | 本地數據遠程數據的訪問接口 |
新秀VIPER
viper這裏不多說了,請想了解的自行搜索
