移動App架構設計

標籤：api   cti   維護   vhd   service   web   架構設計   post   out   

移動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, 把client應用程式分解為有層次的父子關係的MVC, 重複應用這個模式, 形成結構化的client架構. 適合重型B/S架構的WebApp.

一個MVC模組由應用程式的一個模組抽象而成. 當中非常重要的一個概念就是 Parent MVC , 它能夠相應介面上的實體, 也能夠是一個抽象的對象. 設想一個app 有標籤欄, 工具列, 導覽列, 主工作區, 相應到HMVC上就是這個app最底部的標籤欄 是 Layer1, Layer2 導覽列,主要工作區, 工具列. 假設認為 Layer2 太複雜能夠吧主要工作區放到 Layer3, 依次類推.

Controller 是功能模組的總控室, 它負責和子Controller或父Controller通訊，並通知它的 View 處理改變介面顯示, Model 處理一些商務邏輯或資料庫訪問操作. 如才的範例裡, 點擊了工具列裡的一個button, 工具列的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這裡不多說了,請想瞭解的自行搜尋

移動App架構設計