移動App架構模式，移動app架構

移動App架構模式，移動app架構
移動App架構模式

本文主要總結了幾種常用的架構模式, 基本是層層遞進的, 轉載請注名出處: http://blog.csdn.net/uxyheaven

在一個app的不同生命週期採用不同的架構模式可以有效提高開發效率

基本的MVC

移動app一般都是採用經典的mvc架構

層次	作用	設計原則
模型層(model)	封裝了應用的一系列資料, 並定義了操作, 處理這些資料的邏輯和計算規則。	通過C：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 可以呈現的東西.

三層架構

我們在來看一下經典的三層架構

從上至下為

• 展示層(UI)
• 商務邏輯層或稱為領域層(BLL)
• 資料訪問層(DAL)

層次	作用	設計原則
展示層(UI)	向使用者展現特定業務資料，採集使用者的輸入資訊和操作	使用者至上，兼顧簡潔；不包含任何業務相關的邏輯處理
商務邏輯層(BLL)	從ＤＡＬ中擷取資料, 在ＵＩ顯示; 從ＵＩ中擷取使用者指令和資料, 執行商務邏輯或通過ＤＡＬ寫入資料來源	作為U層與Ｄ層的橋樑,目的在於展現清晰的函數結構, 只負責資料處理傳遞, 不涉及ＳＱＬ語句和ＡＤＯ.ＮＥＴ
資料訪問層(DAL)	直接操作資料庫，針對資料的增添 刪除 修改 尋找; 具體為商務邏輯層或展示層提供資料服務。	專門操作資料庫, 不考慮資料合法性. 資料庫錯誤返回－1, 邏輯錯誤返回0, 並告知錯誤原因, 成功返回1

然後呢,我們現在的架構則是

四層架構

在三層架構的基礎上多了商務規則層, 常的三層是把商務邏輯和商務規則合并為一個層，統稱為業務層.商務規則層的提出,既可以及時處理使用者輸入的不合法資訊, 又可以及時處理資料庫錯誤, 增大了商務邏輯層的結構清晰度, 讓商務邏輯人員專心致志做邏輯

從上至下為

• 展示層
• 商務規則層
• 商務邏輯層或稱為領域層
• 資料訪問層

層次	作用	設計原則
商務規則層(ECL)	對於UI層傳下來的參數來說，檢查合法性。	使用者至上，兼顧簡潔；不包含任何業務相關的邏輯處理

五層架構

一般情況下, 我們的商務邏輯放在中介層, 那麼對內部的這些大量種類繁多，使用方法也各異的不同的類的調用任務，就完全落到了展示層. 這樣勢必會增加展示層的代碼量, 將展示層的任務複雜化, 和展示層只負責接受使用者的輸入並返回結果的任務不太相稱, 並增加了層與層之間的耦合程度. 因此呢,我們需要增加介面去去統一的管理這些業務, 是設計模式中Facade模式的思想.

從上至下為

• 展示層
• 業務外觀層
• 商務規則層
• 商務邏輯層或稱為領域層
• 資料訪問層

層次	作用	設計原則
業務外觀層	為負責子系統中的一組介面提供一個一致而且簡單的介面。

新秀VIPER

viper這裡不多說了,請想瞭解的自行搜尋

一般設計移動app產品原型的話用什軟體比較好？用axure設計是不是特別麻煩？

一般你設計初稿可以用balsamiq mockups，如果要進階，加入邏輯關係這些，推薦你還是用axure。

關於產品原型，在於你能否表達到位，有些時候你甚至可以通過紙上手繪來向你的項目群組成員去表達你的思想
 
問IOS app開發 程式架構怎弄好

推薦你一本書，《objective-c編程之道 IOS設計模式解析》