這次來(lái)講MVC中***的M。

Model，幾乎可以說(shuō)是網(wǎng)頁(yè)應(yīng)用的核心。

之前課程提到過(guò)網(wǎng)頁(yè)應(yīng)用是由數(shù)據(jù)庫(kù)驅(qū)動(dòng)，而在很多場(chǎng)景，數(shù)據(jù)庫(kù) = M ； M = 數(shù)據(jù)庫(kù)。

所謂的ORM； object relational mapping。

現(xiàn)在新的網(wǎng)頁(yè)開(kāi)發(fā)框架，特別是MVC框架，都會(huì)提供ORM支持，避免程序員直接寫(xiě)SQL、操作數(shù)據(jù)庫(kù)。

傳統(tǒng)上，ASP/ php臭名昭著的sql注入問(wèn)題，便是因?yàn)椴锁B(niǎo)程序員直接在程序中根據(jù)用戶輸入拼接數(shù)據(jù)庫(kù)造成的；而使用ORM框架，則可以徹底避免這種問(wèn)題。

ORM有兩種風(fēng)格，一種是 R => O；一種是 O => R 。

====== R => O ======

傳統(tǒng)上，程序員也都是先完成數(shù)據(jù)庫(kù)設(shè)計(jì)（甚至是由DBA完成），然后再考慮相應(yīng)的對(duì)象生成，也就是所謂的 R =＞　O。

在這樣的場(chǎng)景下，整個(gè)軟件的框架，還是以數(shù)據(jù)庫(kù)為核心，業(yè)務(wù)的設(shè)計(jì)思維是以關(guān)系型數(shù)據(jù)庫(kù)的表結(jié)構(gòu)為基礎(chǔ)去考慮的，具體應(yīng)用實(shí)現(xiàn)上，會(huì)考慮很多關(guān)系型數(shù)據(jù)庫(kù)的功能特性，比方說(shuō)，外鍵，joining等等，并且，程序員需要直接考慮“數(shù)據(jù)庫(kù)設(shè)計(jì)三范式”，以及冗余字段等面向數(shù)據(jù)庫(kù)的優(yōu)化手段。

并且，程序員也很可能會(huì)采用數(shù)據(jù)庫(kù)的一些高級(jí)特性，如視圖、存儲(chǔ)過(guò)程、甚至觸發(fā)器等等以方便使用。

O的存在，僅僅是為了方便操作數(shù)據(jù)庫(kù)表。

====== O => R ======

這種設(shè)計(jì)哲學(xué)則是相反，程序員做業(yè)務(wù)分析、實(shí)現(xiàn)架構(gòu)設(shè)計(jì)的時(shí)候，并不過(guò)多考慮數(shù)據(jù)庫(kù)的特性與限制；程序僅考慮自己的業(yè)務(wù)對(duì)象：編程語(yǔ)言中的對(duì)象。

數(shù)據(jù)庫(kù)僅僅只是作為一個(gè)對(duì)象持久層來(lái)考慮：

* 程序運(yùn)行的時(shí)候，對(duì)象是自動(dòng)保持在內(nèi)存中。

* 但在對(duì)象狀態(tài)改變、程序退出的時(shí)候，將對(duì)象保存進(jìn)數(shù)據(jù)庫(kù)。

* 程序重新啟動(dòng)的時(shí)候，則從數(shù)據(jù)庫(kù)中獲得原先數(shù)據(jù)，并還原為內(nèi)存中的對(duì)象。

在這樣的場(chǎng)景下，數(shù)據(jù)庫(kù)是一個(gè)可以被替換的存儲(chǔ)層，它可以是關(guān)系型數(shù)據(jù)庫(kù)，也可以是NoSQL，甚至是硬盤(pán)文件；所以，即便使用關(guān)系型數(shù)據(jù)庫(kù)，一般也不會(huì)使用其高級(jí)功能。

設(shè)計(jì)哲學(xué)的不同直接造成了使用技術(shù)的不同。

====== 比較 ======

在ED開(kāi)發(fā)圣經(jīng)PEAA中，列舉了下面三種方案：

1. Trascation Script

也就是直接拼接SQL啦～

2. Table Module

R => O；并且，O非常簡(jiǎn)單，直接以類(lèi)似數(shù)組的方式讀取表數(shù)據(jù)。

.net中ADO.net的DataTable / DataRow對(duì)象便是這種設(shè)計(jì)的典型實(shí)現(xiàn)。

3. Domain Model

O => R，直接設(shè)計(jì)業(yè)務(wù)領(lǐng)域(Domain)的對(duì)象，然后在考慮對(duì)象的持久化方案。

針對(duì)上面3中方案，Martin Fowler畫(huà)了下面這張著名圖解：
http://www.hamishgraham.net/page/Work-Habits.aspx/Architecture/Business-Layer

他的結(jié)論是：

使用Table Module的方式，永遠(yuǎn)比直接寫(xiě)SQL簡(jiǎn)單；在簡(jiǎn)單的業(yè)務(wù)場(chǎng)景下，Table Module也會(huì)比Domain Model簡(jiǎn)單，但Table Module的方案復(fù)雜度會(huì)隨著業(yè)務(wù)復(fù)雜化而快速增長(zhǎng)。

反之，Domain Model的復(fù)雜度跟業(yè)務(wù)復(fù)雜度相比始終保持水平增長(zhǎng)；它雖然一開(kāi)始最復(fù)雜，但隨著業(yè)務(wù)復(fù)雜度超過(guò)一定程度后，它反而會(huì)成為最簡(jiǎn)單的方案。

就我自己的開(kāi)發(fā)經(jīng)驗(yàn)，基本與Fowler的描述吻合；但隨著ORM技術(shù)的成熟，Domain Model，未必如他在圖中畫(huà)的那樣，一開(kāi)始就有那么高的復(fù)雜度。

關(guān)鍵是看程序員是否習(xí)慣于關(guān)系型數(shù)據(jù)庫(kù)的實(shí)現(xiàn)方案，如果是，那么，切換去Domain Model，確實(shí)會(huì)比較麻煩，各種不適應(yīng)。

但如果是一個(gè)沒(méi)有關(guān)系型數(shù)據(jù)庫(kù)經(jīng)驗(yàn)的程序員，或者說(shuō)，沒(méi)有強(qiáng)制使用SQL思維習(xí)慣的程序員，使用Domain Model，也可以是很自然的方案。

下一課，講繼續(xù)詳細(xì)說(shuō)明Domain Model。

作業(yè)：

1. ED開(kāi)發(fā)圣經(jīng)PEAA究竟是哪本書(shū)？

2. 數(shù)據(jù)庫(kù)三范式是什么？

3. 關(guān)于Domain Model，什么是充血模型？什么是貧血模型？

51CTO系列：

1. 宅男程序員給老婆的計(jì)算機(jī)課程之0：認(rèn)清本質(zhì)
2. 宅男程序員給老婆的計(jì)算機(jī)課程之1：認(rèn)清實(shí)際
3. 宅男程序員給老婆的計(jì)算機(jī)課程之2:怎么看待牛人
4. 宅男程序員給老婆的計(jì)算機(jī)課程之3:架構(gòu)比較
5. 宅男程序員給老婆的計(jì)算機(jī)課程之4:SQL vs NoSQL
6. 宅男程序員給老婆的計(jì)算機(jī)課程之5:設(shè)計(jì)模式
7. 宅男程序員給老婆的計(jì)算機(jī)課程之6:模版引擎
8. 宅男程序員給老婆的計(jì)算機(jī)課程之7：運(yùn)維的重要性
9. 宅男程序員給老婆的計(jì)算機(jī)課程之8：控制器