宅男程序員給老婆的計算機課程之9：數據模型
原創這次來講MVC中***的M。
Model，幾乎可以說是網頁應用的核心。
之前課程提到過網頁應用是由數據庫驅動，而在很多場景，數據庫 = M ； M = 數據庫。
所謂的ORM； object relational mapping。
現在新的網頁開發框架，特別是MVC框架，都會提供ORM支持，避免程序員直接寫SQL、操作數據庫。
傳統上，ASP/ php臭名昭著的sql注入問題，便是因為菜鳥程序員直接在程序中根據用戶輸入拼接數據庫造成的；而使用ORM框架，則可以徹底避免這種問題。
ORM有兩種風格，一種是 R => O；一種是 O => R 。
====== R => O ======
傳統上，程序員也都是先完成數據庫設計（甚至是由DBA完成），然后再考慮相應的對象生成，也就是所謂的 R =＞ O。
在這樣的場景下，整個軟件的框架，還是以數據庫為核心，業務的設計思維是以關系型數據庫的表結構為基礎去考慮的，具體應用實現上，會考慮很多關系型數據庫的功能特性，比方說，外鍵，joining等等，并且，程序員需要直接考慮“數據庫設計三范式”，以及冗余字段等面向數據庫的優化手段。
并且，程序員也很可能會采用數據庫的一些高級特性，如視圖、存儲過程、甚至觸發器等等以方便使用。
O的存在，僅僅是為了方便操作數據庫表。
====== O => R ======
這種設計哲學則是相反，程序員做業務分析、實現架構設計的時候，并不過多考慮數據庫的特性與限制；程序僅考慮自己的業務對象：編程語言中的對象。
數據庫僅僅只是作為一個對象持久層來考慮：
* 程序運行的時候，對象是自動保持在內存中。
* 但在對象狀態改變、程序退出的時候，將對象保存進數據庫。
* 程序重新啟動的時候，則從數據庫中獲得原先數據，并還原為內存中的對象。
在這樣的場景下，數據庫是一個可以被替換的存儲層，它可以是關系型數據庫，也可以是NoSQL，甚至是硬盤文件；所以，即便使用關系型數據庫，一般也不會使用其高級功能。
設計哲學的不同直接造成了使用技術的不同。
====== 比較 ======
在ED開發圣經PEAA中，列舉了下面三種方案：
1. Trascation Script
也就是直接拼接SQL啦～
2. Table Module
R => O；并且，O非常簡單，直接以類似數組的方式讀取表數據。
.net中ADO.net的DataTable / DataRow對象便是這種設計的典型實現。
3. Domain Model
O => R，直接設計業務領域(Domain)的對象，然后在考慮對象的持久化方案。
針對上面3中方案，Martin Fowler畫了下面這張著名圖解：
http://www.hamishgraham.net/page/Work-Habits.aspx/Architecture/Business-Layer
他的結論是：
使用Table Module的方式，永遠比直接寫SQL簡單；在簡單的業務場景下，Table Module也會比Domain Model簡單，但Table Module的方案復雜度會隨著業務復雜化而快速增長。
反之，Domain Model的復雜度跟業務復雜度相比始終保持水平增長；它雖然一開始最復雜，但隨著業務復雜度超過一定程度后，它反而會成為最簡單的方案。
就我自己的開發經驗，基本與Fowler的描述吻合；但隨著ORM技術的成熟，Domain Model，未必如他在圖中畫的那樣，一開始就有那么高的復雜度。
關鍵是看程序員是否習慣于關系型數據庫的實現方案，如果是，那么，切換去Domain Model，確實會比較麻煩，各種不適應。
但如果是一個沒有關系型數據庫經驗的程序員，或者說，沒有強制使用SQL思維習慣的程序員，使用Domain Model，也可以是很自然的方案。
下一課，講繼續詳細說明Domain Model。
作業：
1. ED開發圣經PEAA究竟是哪本書？
2. 數據庫三范式是什么？
3. 關于Domain Model，什么是充血模型？什么是貧血模型？
51CTO系列：
