面向對象建模方法與數據庫建模方法的比較

咱們知道：軟件開發通常分爲五個階段：分析、設計、編程、調試、部署和運行。

 

編程階段咱們一般採用Java/.NET這樣面向對象的 語言，使用面向對象的語言能夠爲咱們帶來不少設計上的好處。不過好多時候，在開發過程當中咱們會錯誤的使用面嚮對象語言，具體的表現就是用面向對象的語言來 編寫過程式的代碼。咱們開發軟件就是將現實世界的東西對應到計算機世界中，如何作好現實世界與計算機世界間的映射，是判斷軟件產品好壞的標準。目前，將需求從客觀現實世界映射到計算機軟件世界主要有兩種方式：傳統的數據庫分析設計和面向對象建模(object-oriented class model)

在 分析階段，採用哪一種建模方式決定了後面編程階段的編程特色。若是以數據表爲核心進行分析設計，也就是根據需求首先獲得數據表名和數據字段，接下來的編程工 做只須要咱們學會sql語句操做這些數據表，軟件中的活動就是數據表先後順序的操做（具體的操做就是crud），必然咱們的代碼會成爲過程式的代碼。

相反，在分析階段，咱們根據需求採用面向對象建模的方法，那麼咱們使用面向對象的語言，再加上框架的輔助，就很瓜熟蒂落走上OO編程風格。

下面咱們來看看兩種建模方法是如何來表達客觀世界的。

 

面向對象的模型（Class Model）

 

面向對象模型的核心：類、對象、關係

 

類與對象

 

類（class）是一種面向對象計算機編程語言的構造，是建立對象的藍圖，描述了所建立的對象共同的屬性和方法。類的更嚴格的定義是由某種特定的元數據所組成的內聚的包。它描述了一些對象的行爲規則，而這些對象就被稱爲該類的實例。類的概念和對象的概念是緊密交織在一塊兒的，對象是存在於時間和空間中的具體的實體，而類僅表明一種抽象，即一個對象的「本質」。

 

類的關係

 

類與類的關係其實就是對象間的關係，具體的關係有：依賴、依賴、聚合、組合

具體的關於對象的關係和數據庫的關係能夠參看文章：領域驅動設計之model的關係及ef建模

面向對象模型遵循的基本原則有：抽象、封裝、模塊化以及層次原則等

 

抽象

 

抽象是處理現實世界複雜性的最基本方式在OO方法中它強調一個對象和其餘對象相區別的本質特性對於一個給定的域肯定合理的抽象集是面向對象建模的關鍵問題之一

 

封裝

 

封裝是對抽象元素的劃分過程抽象由結構和行爲組成封裝用來分離抽象的原始接口和它的執行

封裝也稱爲信息隱藏Information Hiding它將一個對象的外部特徵和內部的執行細節分割開來並將後者對其餘對象隱藏起來

 

模塊化

 

模塊化是已經被分爲一系列彙集的和耦合的模塊的系統特性對於一個給定的問題肯定正確的模塊集幾乎與肯定正確的抽象集同樣困難一般每一個模塊應該足夠簡單以便可以被完整地理解

 

層次

 

抽象集一般造成一個層次，層次是對抽象的歸類和排序。在複雜的現實世界中有兩種很是重要的層次一個是類型層次另外一個是結構性層次 。肯定抽象的層次是基於對象的繼承，它有助於在對象的繼承中發現抽象間的關係，搞清問題的所在理解問題的本質

 

數據庫模型(Database Model 傳統E-R模型 )

 

好了，下面咱們談論關係數據表模型，之前咱們樸素的分析設計都是根據需求直接創建數據表的方式來進行的，爲何稱爲樸素， 是由於咱們好像只有數據結構 算法方面的知識，也認爲只有這樣作才叫作軟件。 那麼既然這條路可以走出來，咱們看看這個領域是如何映射客觀世界的。

 

數據表因爲技術提供龐大數據存儲和可靠的數據訪問，正在不斷從技術領域走向社會領域，不少不懂計算機的人 也知道須要創建數據庫來管理一些事務，可是不表明咱們就必須圍繞數據庫的分析設計。

 

數據表是相似前面的「類」，也是一種表達客觀世界的基本單元，表有多列字段，表的字段是保存數據的，每一個字段有數據類型。 注意，這裏沒有數據的封裝和公開，表的字段是赤裸的，只要有數據庫訪問權限，任何人均可以訪問，沒有結構層次關係， 都是扁平並列的。

 

數據表也有一些行爲，這些行爲是基於實體的一些規則：

 

約束(Constraints) 可以保證不一樣表字段之間的關係完整安全性，保證數據庫的數據安全。

 

觸發器(Triggers)提供了實體在修改 新增和刪除以前或以後的一些附加行爲，

存 儲過程(Database stored procedures)提供數據專有的腳本性語言，存儲過程象一個數學公式雖然具備抽象簡潔美學，可是這種簡潔是悶葫蘆美學，不是大衆美學，只有公式存儲 過程發明者本身瞭解精通，別人沒法插手，軟件不是科學，不是比誰智商高，科研水平高，軟件是人機工程，更講究集體，講究別人是否方便與你協同擴展軟件。

 

關 係數據表的遍歷訪問是經過列字段遍歷或表join等方式實現，SQL語句是這樣標準語言， 只要會寫SQL語句，就能訪問那些失去層次，失去客觀世界特徵的蒼白的數據，這樣的系統可以多少真實 反映客觀需求，是有問號的？SQL語句是否方便修改，是否經得起頻繁修改而不出錯，都是有疑問的地方，是否 SQL語句越複雜，修改越快，或者另一個程序員可以很快修改不是本身寫的SQL語句，這些都是問題所在。

 

數據表關係

 

數 據表的關係主要是經過外健或專門關聯表來表達的，這種關係雖然能夠反映1:1或1:N這樣關係，可是沒法 表達關係的性質，是緊密組成關係式的關聯，仍是可有可無的普通關係，正由於如此，使用數據表分析設計時， 咱們會有蜘蛛網的關係表，這些關係因爲在後期沒法分辨性質，沒法進行整理，增長了系統複雜性。

 

更重要的是：分析就是對一個可能陌生領域進行 探尋，若是使用數據表的分析設計方法，那麼咱們實際就是 在陌生領域中尋找數據表這樣一個形式，那麼有可能產生誤判斷，將一個實則是表達關係的東東誤認爲是一個實體表， 由於關係表必然帶來關係，這樣，就必然產生蜘蛛網式的數據表模型，將簡單問題複雜化。

 

兩種建模方法對應的模型

面向對象建模的方法在開發過程當中使用領域驅動設計的方法開發更爲友好

傳統的數據庫分析設計的方法咱們在開發過程當中更多的使用貧血模型