宅男程序員給老婆的計算機課程之9：數據模型

時間 2020-04-07

標籤程序員老婆計算機課程數據模型欄目快樂工作简体版

原文原文鏈接

此次來說MVC中最後的M。php

Model，幾乎能夠說是網頁應用的核心。程序員

以前課程提到過網頁應用是由數據庫驅動，而在不少場景，數據庫 = M ； M = 數據庫。sql

所謂的ORM； object relational mapping。數據庫

如今新的網頁開發框架，特別是MVC框架，都會提供ORM支持，避免程序員直接寫SQL、操做數據庫。編程

傳統上，ASP/ php臭名昭著的sql注入問題，即是由於菜鳥程序員直接在程序中根據用戶輸入拼接數據庫形成的；而使用ORM框架，則能夠完全避免這種問題。設計模式

ORM有兩種風格，一種是 R => O；一種是 O => R 。數組

====== R => O ======架構

傳統上，程序員也都是先完成數據庫設計（甚至是由DBA完成），而後再考慮相應的對象生成，也就是所謂的 R =＞　O。app

在這樣的場景下，整個軟件的框架，仍是以數據庫爲核心，業務的設計思惟是以關係型數據庫的表結構爲基礎去考慮的，具體應用實現上，會考慮不少關係型數據庫的功能特性，比方說，外鍵，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系列：

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。