martin fowler這本《企業應用架構模式》應該是家喻戶曉了，買了也有些日子，一直沒有拿起來看，現在終於輪到了這本書。
這本書大致分為兩部分，前8章為第乙個部分，對企業級開發要涉及的東西進行初步的介紹，然後還概括性的講解了一些模式的適用場景和優缺點。第二部分是模式的列表，這些模式的分類就是按照第一部分介紹的企業級開發要注意的方面來分的。現在我只看完了第一部分。
martin的理由是，企業級應用關注的是領域的業務邏輯，這個業務邏輯非常複雜，而對比如電信行業的系統大吞吐量、高併發關注的比較少。
針對企業級應用的特點，martin總結出一些共有的特徵：
persistent data:一般企業級應用都要將資料持久化起來（不過這個，貌似當今的大部分系統都是如此）
a lot of data:資料量大，這個也許比起當今的web 2.0**，有點小巫見大巫了，不過也看什麼行業吧
access data concurrently:事務:這個倒是真的，一般企業級應用我想都跟錢有很密切的關係，事務處理貌似很常見（個人感觸）
a lot of user inte***ce screens:許多使用者介面，這個也是，乙個系統密密麻麻的介面，不過有人說當今的web 2.0應用介面更多啊，那個海量啊。不過web 2.0的**介面是多，但大部分是相同的，只是資料不同而已，而企業級應用裡就是一堆堆不相同的介面
使用者技術層次不高:這個說到我心坎上了，企業級應用一般面對的都是別的領域裡的人，他們跟我們it人員的思維很多不一樣，這個是個比較麻煩的事兒
與其他系統整合，別說了，我現在還在為這個苦惱呢，現在正在做乙個整合的東西。如果所有系統都是我們一家開發的倒好說，現在各家開發的，使用的技術也千奇百怪，這個倒好說，各家扯起皮來頭就痛。
上面雖然舉出了很多特徵，但是只有少數比較有感觸，感觸最多的還是業務邏輯的複雜性，做企業級應用的最大的難點我覺得應該是一幫it人員去跟一幫別的行業的使用者打交道，我記得剛工作那會兒，頭頭帶著我去現場，客戶談的天花亂墜，我就像乙個傻瓜，什麼採收率、什麼剩餘油分布我是乙個也聽不懂，沒辦法，後來買幾本石油的書自己看。還有乙個感觸是，企業級應用裡技術比較落後，一切都講究穩妥。還有在擴充套件方面，因為企業有錢，在某些東西遇到瓶頸的時候都以購買效能更好的硬體來解決，很少有橫向擴充套件的方式，所以很鬱悶的不能嘗試一些很潮的架構（比如老趙最近寫的關於key/value資料庫以及資料分割槽的幾篇文章）。
在這裡還是離不開那個經典又該死的三層架構。這裡列出了一張表：
分層職責
展示層提供服務，顯示資訊（比如視窗裡和html裡，處理使用者請求，http請求等
領域層邏輯，系統的真正核心部分
資料訪問
與資料庫啊、訊息系統、事務管理器以及其他系統通訊的部分（不僅僅是運算元據庫哦）
在這裡沒什麼說的，就是這個領域層，在工作之前，我做的東西都是web，而且大部分還是什麼新聞啊，論壇之類的。那個時候天天看這個三層架構，為啥就多個業務邏輯層呢，沒啥邏輯啊，但是為了「證明」我是用的三層架構，我就也新增了乙個業務邏輯層，但實際上那個層僅僅就乙個proxy，將介面呼叫過來的方法直接傳遞給資料訪問層。二層就夠了，那個時候實際上沒有理解分層的意義，不要為了分層而分層，分層是為了劃分層與層之間的職責，劃分層的邊界，將變化抑制在層內，不要層間擴散。如果簡單到只需要兩層，那就兩層唄。
不過工作了卻不一樣了，現在做的系統，寫**最多的地方就是業務邏輯層，所以這個層的職責也就體現出來了。
在這裡martin還教了乙個方法來判斷，哪些東西該放到業務邏輯層，哪些是介面上的邏輯：
新增乙個相同的層，比如你現在做個web應用，是不是已經有個展示層了，那你還新增乙個展示層，這次用控制台的方式來實現展示層，你看看用html方式的展示層和控制台的方式實現的展示層之間有哪些重複的**，將重複的**轉移到業務邏輯層中去吧。
呵呵，這個方法對你可能沒啥用，對我確實不錯，貌似也一直這麼幹的，我們的系統大部分都是b/s和c/s的都要開發，所以。。。。。
第二章介紹的是如何組織業務邏輯。martin總結了三個主要的模式：事務指令碼、領域模型、表模組。
實際上這三個模式對應的就是面向過程、物件導向、面向資料庫。驚嘆martin的忽悠能力。
事務指令碼？啥是事務指令碼？實際上就是你常常幹的，拼裝個sql語句，搞個查詢，返回個啥，這種過程方式。
而領域模型呢，就是按照職責，建幾個類，每個類僅僅負責自己的職責那部分，物件與物件之間有機的組織在一起。
表模組，實際上就是每張表搞乙個類，乙個單例的類，負責該錶相關的操作。
第三者我沒怎麼用到，對於前兩者，很多人在意識上牴觸事務指令碼，說這種是過程化的產物。但實際上對一些簡單的應用，比如報表，業務邏輯非常簡單，直來直去的，還不是經常變化，那事務指令碼就是絕佳的啊，你還搞幾個物件累不累。
而當業務邏輯有點不確定，比如裡面還有根據什麼東西的型別然後決定執行什麼操作的**，那你就不要搞一堆的if else或switch出來了，搞個物件層次來處理這個吧。但是做領域模型的時候，你首先要花點思考職責的問題，什麼物件負責哪乙個都想一想。
第三章，對映到關聯式資料庫，這可是個大話題。這一章篇幅也比較大，講了很多實際開發中要面臨的問題。
在說martin的之前我先說幾點我碰到的問題：
1、要支援多種資料庫，這個做專案還好，做到產品就要求支援oracle、sql server、sysbase，有的時候還要支援access做單機應用。即使是相同的資料庫，還要支援不同的版本，比如有一次在某油田實施，系統老連線不上去，最後沒辦法現場除錯一下唄，最後找到問題是他們用的資料庫還是oracle 6，而我們產品開發的時候用的是oracle 10g，幸虧用的是ibatis.net，改一下就ok了（orm框架的好處）。
2、資料庫已經定了，這個我相信很多做企業級開發的都碰到了，都是針對遺留資料庫開發，裡面有很多歷史資料，不可能要求你重新設計，特別鬱悶的是有的資料表設計的及其不合理，你還不能改。有一次我碰到乙個表，實際上可以分成三張表，但是都放在一張表裡，形成一種「扁平」的結構，我百思不得其解，難道當初設計這資料庫的人這麼菜麼，最後一問，這是因為這張表的資料通常是用感測器採集到資料，然後通過乙個專門裝置存庫的，那個嵌入式裝置存這種扁平的結構比較好存，my god。
3、離線應用，這個也是很多使用者強烈要求的，說如果背個電腦到領導那兒匯報演示，以前都用ppt，領導想看點別的資料看不了，現在既然有你這軟體了，那就用這軟體直接演示吧，但是領導那兒總不好把人家網線給拔了吧，或者出差的時候連不上企業內部網路等，嗯這也是比較頭痛的問題。
上面這是我經常碰到的問題，總結一下。
martin對對映到關聯式資料庫這一塊兒討論比較多，而且我也覺得對映到關聯式資料庫也是日常開發中的重頭戲，所以在本篇文章中就到此位置吧，下篇文章再仔細談談一些注意事項。
買書不看就是浪費，這本書買了一年有多，還是新的一樣，罪過罪過。確確實實的體會到誰說的那句話，現在缺的不是書，是看書的人。
tag標籤:
martin fowler,
poea,
企業應用架構模式
《企業應用架構模式》讀書筆記 4
第九章 領域邏輯模型 坦白來講，這本書到目前為止，前9章都看了有2遍，有些可以理解，有些還是不能理解。領域邏輯模型這一章，對於書中的話 對於程式和例子，都可以明白，但對於思想 該怎麼使用還是似懂非懂。以前做桌面系統多一些，設計和編碼多用的是observer，adapter之類的模式 對於非桌面系統，...
企業應用架構模式讀書筆記 第一章 分層
在分解複雜的軟體系統時，軟體設計者用得最多的技術之一就是分層。當用分層的觀點來考慮系統時，可以將各個子系統想象成按照 多層蛋糕 的形式來組織，每一層都依託在其下層之上。在這種組織方式下，上層使用了下層定義的各種服務，而下層對上層一無所知。另外，每一層對自己的上傳隱藏其下層的細節。因此，第4層使用第3...
《企業應用架構模式》筆記（3）
這部分主要是說表現層和併發。第四章 web表現層模型 檢視 控制器 輸入控制器 控制器處理請求訊息，模型負責領域邏輯，檢視基於模型建立應當訊息。控制器輸入控制器和應用控制器 檢視三種模式 轉換檢視，模板檢視和兩步檢視 兩種選擇 1 使用轉換檢視還是模板檢視。模板檢視 允許在網頁的結構中編寫表現層，並...