建站
咨詢
售后
建站咨詢
新聞中心
【獨(dú)家特稿】在前面的課程中提到PEAA中只有一頁(yè)半的Active Record Pattern ( http://martinfowler.com/eaaCatalog/activeRecord.html )影響了過去5年多6年的Web開發(fā)潮流。
這個(gè)潮流是由Ruby On Rails引領(lǐng)的。
RoR的作者DHH David Heinemeier Hansson是Hacker，他因?yàn)镽oR在2005年被Google跟O'Reilly選為年度黑客。
他在設(shè)計(jì)RoR時(shí)，選用了Active Record作為RoR的M層。
Active Record非常簡(jiǎn)單，一個(gè)類對(duì)應(yīng)一個(gè)表，一個(gè)對(duì)象實(shí)例對(duì)應(yīng)一行數(shù)據(jù)；并且有簡(jiǎn)單的有Save / Delete以及查詢等簡(jiǎn)單的函數(shù)操作。
嚴(yán)格的說(shuō)，Active Record不是福勒所推崇的充血Domain Object模型 （ http://martinfowler.com/bliki/AnemicDomainModel.html ），Active Record對(duì)象提供的功能函數(shù)太少，只有通用的數(shù)據(jù)操作方法，而不包涵業(yè)務(wù)邏輯；但它又不像POJO （ http://martinfowler.com/bliki/POJO.html ） 那樣完全的貧血。
（充血、貧血Domain Object之爭(zhēng)，可以去iteye翻帖子）
從福勒 AnemicDomainModel 一文看，他在當(dāng)年（2003）是推薦了充血Domain對(duì)象跟POJO，但過去幾年在Web開發(fā)領(lǐng)域所流行的卻是 Active Record這樣兩邊都沾點(diǎn)，但卻又不全是的中間妥協(xié)方案。
不搞教條主義，什么實(shí)用用什么，POJO不夠，那么就加一點(diǎn)；充血太復(fù)雜，那么就減少一點(diǎn)。
從互聯(lián)網(wǎng)的發(fā)展看，我一時(shí)間完全想不出有什么在理論上被設(shè)計(jì)得很好的模型，能夠最終經(jīng)歷時(shí)間考驗(yàn)成為事實(shí)標(biāo)準(zhǔn)。
因特網(wǎng)的7層模型，實(shí)際用到的遠(yuǎn)不到7層；Java的EJB掛了；XML被JSON取代等等等等。
也許學(xué)院派提出的理論有他們的應(yīng)用場(chǎng)景，只是，這樣的場(chǎng)景，在快速發(fā)展互聯(lián)網(wǎng)似乎很難找到例子。
互聯(lián)網(wǎng)產(chǎn)品的業(yè)務(wù)相對(duì)簡(jiǎn)單，Active Record已經(jīng)足夠好，足夠方便，因此大行其道。
另一方面，互聯(lián)網(wǎng)產(chǎn)品做大后，也往往有著極大的性能要求，一個(gè)復(fù)雜的模型，是難以做性能優(yōu)化的。
像Active Record，因?yàn)樽銐蚝?jiǎn)單，Twitter在當(dāng)年遇到性能問題的時(shí)候，便直接Hack掉RoR的實(shí)現(xiàn)，增加了 Cache-Money （ https://github.com/nkallen/cache-money ） 這么一個(gè)透明的緩存層。
如果RoR使用的是充血對(duì)象模型，對(duì)象中有復(fù)雜的業(yè)務(wù)邏輯，如何增加透明的緩存呢？
Active Record的實(shí)際上是對(duì)數(shù)據(jù)庫(kù)操作做了抽象。
封裝、抽象是一門藝術(shù)。
什么該封裝，什么該暴露，什么徹底不可見，需要拿捏得很準(zhǔn)確。
最容易犯的錯(cuò)誤是過度封裝，使得一些本來(lái)很簡(jiǎn)單的底層操作，到了上層變得完全不能用；或者說(shuō)，很難用。
開發(fā)者需要用到hack的方式，才能去做這些簡(jiǎn)單的操作。
Active Record便是一個(gè)抽象封裝得恰到好處的例子。過度設(shè)計(jì)、過度封裝的數(shù)據(jù)操作層？EJB。
按照教科書對(duì)OO的定義，OO的核心特性之一是：encapsulation http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29
Private屬性、方法，對(duì)象外部是完全不能訪問的。
但如果遇到了需要訪問的場(chǎng)景怎么辦？！
有的人會(huì)說(shuō)：“這樣的場(chǎng)景本來(lái)就不應(yīng)該出現(xiàn)，這是對(duì)象設(shè)計(jì)一開始沒有做好造成的，錯(cuò)誤的應(yīng)該設(shè)成Public的屬性設(shè)成了Private”。
ORM，采用O => R的映射的設(shè)計(jì)哲學(xué)，只考慮業(yè)務(wù)對(duì)象，完全不考慮底層數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)僅僅是一個(gè)可以被替換掉的持久層，它可以是關(guān)系型數(shù)據(jù)庫(kù)、也可以是NoSQL，甚至是硬盤文件。
也就是說(shuō)，Domain Object是把后端數(shù)據(jù)庫(kù)給設(shè)成“Private”了，即便底層是關(guān)系型數(shù)據(jù)庫(kù)，你也不可以直接去寫SQL。
即便你使用的是MS SQL Server，你也不能去調(diào)用它特有的SQL特性。
Asp.Net剛出來(lái)的時(shí)候，微軟曾經(jīng)鼓吹過一個(gè)叫 N-Tiers 的架構(gòu)：http://msdn.microsoft.com/en-us/library/ms973279.aspx / http://msdn.microsoft.com/en-us/library/bb384398.aspx 。
我曾經(jīng)以為這是王道，直到我膝蓋中了一箭……呃，不，直到我看了Joel Spolsky寫的 The Law of Leaky Abstractions：http://www.joelonsoftware.com/articles/LeakyAbstractions.html
理想很豐滿，現(xiàn)實(shí)很骨感。
ORM工具再怎么封裝都好，底層用了數(shù)據(jù)庫(kù)，就是用了數(shù)據(jù)庫(kù)。
開發(fā)者必然需要了解數(shù)據(jù)庫(kù)的特性，能否直接調(diào)用數(shù)據(jù)庫(kù)的特性，是一個(gè)選擇。
是否要徹底對(duì)上層屏蔽掉數(shù)據(jù)庫(kù)的存在，也是一個(gè)選擇。
N-tiers架構(gòu)推薦一層又一層的封裝，如果錯(cuò)誤使用，把選擇當(dāng)成教條，是會(huì)有噩夢(mèng)的。
========
Python是一門很有趣的語(yǔ)言，它支持繼承，能實(shí)現(xiàn)OO，但是缺乏 encapsulation 的語(yǔ)言支持。
Python根本就沒有public / private這樣的關(guān)鍵字，然后呢？
然后可以回過頭再去看：“這樣的場(chǎng)景本來(lái)就不應(yīng)該出現(xiàn)，這是對(duì)象設(shè)計(jì)一開始沒有做好造成的，錯(cuò)誤的應(yīng)該設(shè)成Public的屬性設(shè)成了Private”。
這句話，這話說(shuō)得對(duì)嘛？
作業(yè)：
1. N-tiers架構(gòu)的噩夢(mèng)場(chǎng)景是？
2. 什么系統(tǒng)/場(chǎng)景需要充分使用特定數(shù)據(jù)庫(kù)的特性？
系列：
- 宅男程序員給老婆的計(jì)算機(jī)課程之0：認(rèn)清本質(zhì)
- 宅男程序員給老婆的計(jì)算機(jī)課程之1：認(rèn)清實(shí)際
- 宅男程序員給老婆的計(jì)算機(jī)課程之2:怎么看待牛人
- 宅男程序員給老婆的計(jì)算機(jī)課程之3:架構(gòu)比較
- 宅男程序員給老婆的計(jì)算機(jī)課程之4:SQL vs NoSQL
- 宅男程序員給老婆的計(jì)算機(jī)課程之5:設(shè)計(jì)模式
- 宅男程序員給老婆的計(jì)算機(jī)課程之6:模版引擎
- 宅男程序員給老婆的計(jì)算機(jī)課程之7：運(yùn)維的重要性
- 宅男程序員給老婆的計(jì)算機(jī)課程之8：控制器
- 宅男程序員給老婆的計(jì)算機(jī)課程之9：數(shù)據(jù)模型
- 宅男程序員給老婆的計(jì)算機(jī)課程之10：做，就對(duì)了！
新聞名稱：宅男程序員給老婆的計(jì)算機(jī)課程之11:域模型
當(dāng)前鏈接：http://www.dlmjj.cn/article/dpcggph.html
