介紹一下手頭乙個系統的軟體結構，先附上圖：
大概分為5層：
檢視層：
作用：系統和使用者進行互動，分離出來，是因為系統修改了介面無需修改業務，甚至於
可以把改寫為wap在手機瀏覽器進行操作。
組成部分：web元件、struts標籤等
應用層：
作用：對業務的複雜性進行了封裝，檢視層的呼叫者無需知道業務邏輯的具體細節，它僅僅知道使用就可以了，作為系統的協調者，接受資料，對資料進行的操作，操作之後所要到達的檢視。
組成部分：控制器、pojp facade（看下方註解）
領域層：
作用：業務邏輯層，在這裡實現所有的業務邏輯，以及建模中抽象出來的模型，嚴格的話可以再用聚合的思路抽象出一些業務邏輯的協調者（比如：轉賬的時候，呼叫了減去餘額和專家餘額2個類，那就可以抽象出乙個協調類，負責一起呼叫這2個類）
組成部分：業務邏輯、模型、業務邏輯協調者（業務 facade）
持久層：
作用：就是把模型、實體等的物件持久化到硬碟
組成部分：hibernate、dao等
公共基礎層：
作用：系統中可以作為基礎功能的一些集合
總結：
註解：
pojo facade：
引自《pojos in action》中的解析，比如：現在汽車是件複雜的機器。它包含
各種機械部件，如：氣缸、輪胎等，也許還提供和有足以把飛船送上月球的接受能力，不過對
於使用者來說，大部分複雜性都不可見，要開動汽車，我們只需和車鑰匙、方向盤、腳剎和變速
檔打交道。這些簡單的控制裝置封裝了汽車內部的複雜性。同樣，對於業務邏輯的客戶表示層
（和控制器）來說，我們也需要隱藏業務邏輯的複雜性。pojo façade在這裡其實就是領域模
型的使用者。因為領域模型最好是用pojo方式編碼（即不依賴於特定的框架，如spring、ejb
，這是業務邏輯編碼的準則）。
iOS架構設計與分層
多人都會說，凡事不能走極端，走了極端就過猶不及。所以應該分層，但不能過分分層，應該視具體情況來定。這樣的話聽起來很有道理，卻只是一句廢話。當我們遇到問題時，還是摸不著頭腦！看看知名的架構師是怎麼說的吧！來自蔡學鏞 我做 開發 架構的幾個原則，根據優先次序高低排列 1.邏輯 拆分越細越好 2.依賴關細...
iOS架構設計與分層
多人都會說，凡事不能走極端，走了極端就過猶不及。所以應該分層，但不能過分分層，應該視具體情況來定。這樣的話聽起來很有道理，卻只是一句廢話。當我們遇到問題時，還是摸不著頭腦！看看知名的架構師是怎麼說的吧！來自蔡學鏞 我做 開發 架構的幾個原則，根據優先次序高低排列 1.邏輯 拆分越細越好 2.依賴關細...
移動App設計之分層架構 MVC
場景分析 我們知道，乙個移動裝置的應用大多與網路有關，也就是說，我在移動裝置上看到的資料，一般都是從server上 拉 過來，顯示在我們的移動裝置 ios androiud wpohone等 上。那我們就這個 拉 的過程分析，拉什麼樣的資料？去 拉？拉過來的資料怎麼處理？用程式設計 開發 的思維看，...