並不是說OOA OOD就不會用到ER喔 只要你的軟體計劃中有需要使用DB，就會有ER或者類似的資料庫模型文件 除非你使用結合DB的OOPL 另外資料庫的stored procedure不是用來給你寫物件的method的 是用來控制資料庫的一致性的，補足DBMS內建constraint的不足 資料庫的功能就是存放重要的資料 你不應該把AP的物件在資料庫中實做 除非你用OODB或ORDBMS 這些資料庫就會提供定義"method"的方法 或者讓你mapping methods到stred procedures ※ 引述《seagal (會長繞跑了)》之銘言： : ※ 引述《come ()》之銘言： : : 我是說先有資料庫才有程式喔 : : 你完全誤會了 : : 這跟class diagram的語意一點都沒關係 : : 這是跟資料庫的設計和整個軟體開發流程的先後順序有關 : : 資料庫是在analysis階段就完成 : 這樣說也是有道理 : 的確ER Model是在分析階段就會產出的文件 : 不過這也是我最主要覺得的問題 : 硬把傳統的結構化分析與設計 : 跟物件導向分析與設計串在一起 : 產生的很多問題 : 都讓我覺得很弔詭 : 結構化的分析與設計 : 起源於1960年代末期 : 最初的結構化的分析與設計 : 並沒有包含ER Model : 到新一代的結構化分析與設計 : 才將ER Model加入 : 我門看陳品山是在1976年提出這個模型就可以得知了 : 直到1986年 : Grady Booch率先發表物件導向的系統開發方法 : 以開啟物件導向在軟體工程上應用的新頁 : 在這幾十年之間 : 關聯式資料模型的變化似乎不大 : 看看現在最流行的兩種OO語言 : Java and .NET : 在支援OOA/OOD上可以說是配合的很好 : 例如簡單的struts, EJB, servlet概念 : 讓架構在OO上的MVC觀念得以完全發揮 : 唯一我覺得有很多疑問的地方 : 就是在關聯式資料庫的部份 : 我這邊舉ASP.NET + SQL Server的例子 : 當我以三層式架構 : 完成我的ASP.NET網站的時候 : 每一層的類別都經過良好的分析與設計 : 配合的天衣無縫 : 卻在資料處理層要與SQL Server溝通時 : 讓我做了很多dirty work : 也就是O/R mapping要處理的議題 : 例如 : 今天我要將新聞模組(News)從資料庫讀出來 或寫入資料庫 : News類別裡面的method我該怎麼實做在呢SQL Server呢? : 為了簡化例子 : 我只需要簡單的兩個方法 getInstance, putInstance : 這樣子就好 : 沒錯 SQL Server可以提供sprocs : 可是光是sprocs命名 : 我就得取名作 : News_getInstance(NewsID) : News_putInstance(NewsID) : 這兩支 : 如果我每個類別有二十個方法呢 : 如果我有二十個類別呢? : 我的sprocs就會有400個 : 事實上有些method是應該被封裝起來的 : 所以也不應該被其他method存取到 : 從sprocs拿出來的資料 : 交給ASP.NET處理的時候 : ASP.NET是利用一種ADO.NET的技術 : 簡單來說就是將資料變成一個table : 你必須要再去讀取每個table裡面的值 : 轉換成你自己的物件 : Oh my god : 我只是要用個OO而已 : 怎麼多出來這麼多個步驟了 : 雖然我還是乖乖做完了:( : 這只是一個小問題而已 : 我再舉出另外兩個問題 : 在OO的思維裡 : 每個物件是不需要PK的 : 你也可以說她們本身就有PK : 因為每個物件都會自己產生獨一無二的ID : 這也是現在的OODB實做的方式 : 而在上面我舉的例子裡面 : 我總是要透過News模組的PK (NewsID)來讀取每個tuple : 最後一個問題 : 在傳統的結構化分析與設計 : 將每個階段都切的十分清楚 : 而如果用OOA/OOD的方式來開發的話 : 並不會產出ER Model的文件(上面提過這是結構化分析 設計的產物) : 有些DBA也沒有學過UML(至少我們team的DBA沒有學過) : 那分析階段產出的UML該由誰負責轉成ER Model呢 : 萬能的SA/SD嘛 : 或是像come網友講的 : 在分析階段就產出ER Model : 後面的設計都繞著ER Model來做? : 這也就是說 : 把OOA/OOD以資料導向的方式來開發? : 我的領域並不在OODB上面 : 我只是最近剛好有需要 : 將生物資訊的大量資料作處理 : 有必要的話可能還是得硬著頭皮弄出適合的一套檔案(or DBMS)系統 : 所以如果有任何高手能指正的話 : 也歡迎針對我說錯的地方指正 : : analysis階段的class diagram只是一個雛形而已 : : 到了design階段的class diagram還必須根據data base schema重新設計一次 : : 那你覺得這時候class diagram的設計是要遷就DB : : 還是要回頭改DB設計? : : spiral model的開發模型是可以這樣搞 : : 不過改到DB通常表示需求分析有問題 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.223.42.62