宅男程序員給老婆的計算機課程之11:域模型

【51CTO獨家特稿】在前面的課程中提到PEAA中只有一頁半的Active Record Pattern ( http://martinfowler.com/eaaCatalog/activeRecord.html )影響了過去5年多6年的Web開發潮流。

這個潮流是由Ruby On Rails引領的。

RoR的做者DHH David Heinemeier Hansson是Hacker，他由於RoR在2005年被Google跟O'Reilly選爲年度***。

他在設計RoR時，選用了Active Record做爲RoR的M層。

Active Record很是簡單，一個類對應一個表，一個對象實例對應一行數據；而且有簡單的有Save / Delete以及查詢等簡單的函數操做。

嚴格的說，Active Record不是福勒所推崇的充血Domain Object模型 （ http://martinfowler.com/bliki/AnemicDomainModel.html ），Active Record對象提供的功能函數太少，只有通用的數據操做方法，而不包涵業務邏輯；但它又不像POJO （ http://martinfowler.com/bliki/POJO.html ） 那樣徹底的貧血。

（充血、貧血Domain Object之爭，能夠去iteye翻帖子）

從福勒 AnemicDomainModel 一文看，他在當年（2003）是推薦了充血Domain對象跟POJO，但過去幾年在Web開發領域所流行的倒是 Active Record這樣兩邊都沾點，但卻又不全是的中間妥協方案。

不搞教條主義，什麼實用用什麼，POJO不夠，那麼就加一點；充血太複雜，那麼就減小一點。

從互聯網的發展看，我一時間徹底想不出有什麼在理論上被設計得很好的模型，可以最終經歷時間考驗成爲事實標準。

因特網的7層模型，實際用到的遠不到7層；Java的EJB掛了；XML被JSON取代等等等等。

也許學院派提出的理論有他們的應用場景，只是，這樣的場景，在快速發展互聯網彷佛很難找到例子。

互聯網產品的業務相對簡單，Active Record已經足夠好，足夠方便，所以大行其道。

另外一方面，互聯網產品作大後，也每每有着極大的性能要求，一個複雜的模型，是難以作性能優化的。

像Active Record，由於足夠簡單，Twitter在當年遇到性能問題的時候，便直接Hack掉RoR的實現，增長了 Cache-Money （ https://github.com/nkallen/cache-money ） 這麼一個透明的緩存層。

若是RoR使用的是充血對象模型，對象中有複雜的業務邏輯，如何增長透明的緩存呢？

Active Record的其實是對數據庫操做作了抽象。

封裝、抽象是一門藝術。

什麼該封裝，什麼該暴露，什麼完全不可見，須要拿捏得很準確。

最容易犯的錯誤是過分封裝，使得一些原本很簡單的底層操做，到了上層變得徹底不能用；或者說，很難用。

開發者須要用到hack的方式，才能去作這些簡單的操做。

Active Record即是一個抽象封裝得恰到好處的例子。過分設計、過分封裝的數據操做層？EJB。

按照教科書對OO的定義，OO的核心特性之一是：encapsulation http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29

Private屬性、方法，對象外部是徹底不能訪問的。

但若是遇到了須要訪問的場景怎麼辦？！

有的人會說：「這樣的場景原本就不該該出現，這是對象設計一開始沒有作好形成的，錯誤的應該設成Public的屬性設成了Private」。

ORM，採用O => R的映射的設計哲學，只考慮業務對象，徹底不考慮底層數據庫，數據庫僅僅是一個能夠被替換掉的持久層，它能夠是關係型數據庫、也能夠是NoSQL，甚至是硬盤文件。

也就是說，Domain Object是把後端數據庫給設成「Private」了，即使底層是關係型數據庫，你也不能夠直接去寫SQL。

即使你使用的是MS SQL Server，你也不能去調用它特有的SQL特性。

Asp.Net剛出來的時候，微軟曾經鼓吹過一個叫 N-Tiers 的架構：http://msdn.microsoft.com/en-us/library/ms973279.aspx / http://msdn.microsoft.com/en-us/library/bb384398.aspx 。

我曾經覺得這是王道，直到我膝蓋中了一箭……呃，不，直到我看了Joel Spolsky寫的 The Law of Leaky Abstractions：http://www.joelonsoftware.com/articles/LeakyAbstractions.html

理想很豐滿，現實很骨感。

ORM工具再怎麼封裝都好，底層用了數據庫，就是用了數據庫。

開發者必然須要瞭解數據庫的特性，可否直接調用數據庫的特性，是一個選擇。

是否要完全對上層屏蔽掉數據庫的存在，也是一個選擇。

N-tiers架構推薦一層又一層的封裝，若是錯誤使用，把選擇當成教條，是會有噩夢的。

========

Python是一門頗有趣的語言，它支持繼承，能實現OO，可是缺少 encapsulation 的語言支持。

Python根本就沒有public / private這樣的關鍵字，而後呢？

而後能夠回過頭再去看：「這樣的場景原本就不該該出現，這是對象設計一開始沒有作好形成的，錯誤的應該設成Public的屬性設成了Private」。

這句話，這話說得對嘛？

做業：

1. N-tiers架構的噩夢場景是？

2. 什麼系統/場景須要充分使用特定數據庫的特性？

51CTO系列：

1. 宅男程序員給老婆的計算機課程之0：認清本質
2. 宅男程序員給老婆的計算機課程之1：認清實際
3. 宅男程序員給老婆的計算機課程之2:怎麼看待牛人
4. 宅男程序員給老婆的計算機課程之3:架構比較
5. 宅男程序員給老婆的計算機課程之4:SQL vs NoSQL
6. 宅男程序員給老婆的計算機課程之5:設計模式
7. 宅男程序員給老婆的計算機課程之6:模版引擎
8. 宅男程序員給老婆的計算機課程之7：運維的重要性
9. 宅男程序員給老婆的計算機課程之8：控制器
10. 宅男程序員給老婆的計算機課程之9：數據模型
11. 宅男程序員給老婆的計算機課程之10：作，就對了！
12. 宅男程序員給老婆的計算機課程之11:域模型