我簡單回一下有關O/R mapping的方面好了 明天要出國 可能沒時間再繼續回了 ㄧ些有名的O/R mapping framework java: Hibernate http://hibernate.bluemars.net/ NET: LINQ http://blog.sina.com.tw/4907/article.php?pbgid=4907&entryid=38437 .NET版本的O/R mapping是我除了OODB之外 第二個期待的新技術 它能夠將資料庫查詢的語法 很完整的整合在程式語言裡頭 而關於O/R mapping該不該用sprocs ㄧ些常用的用法 都是將DAL(資料存取層)直接對應到sprocs上面 這絕對不是我自己亂搞的 http://www.devx.com/vb2themax/Article/19894/0/page/3 而我之前在處理這些對應的時候 當然也是按照上面的方法去做的 但我在思考 真的ㄧ定得做這些事情嗎? OOA/OODㄧ定得跟結構化分析設計方法搭上邊嗎(這兩個明明就是兩套分析方法)? 我不能從頭到尾都用OO嗎?(這樣不是應該很理所當然的事情嗎) 舉一個例子 或許可以用XML的方式來做persistence 或許可以期待OODB 或許我的survey還不夠 應該趕快唸書去 不要再玩逼逼了 ※ 引述《come ()》之銘言： : 並不是說OOA OOD就不會用到ER喔 : 只要你的軟體計劃中有需要使用DB，就會有ER或者類似的資料庫模型文件 : 除非你使用結合DB的OOPL : 另外資料庫的stored procedure不是用來給你寫物件的method的 : 是用來控制資料庫的一致性的，補足DBMS內建constraint的不足 : 資料庫的功能就是存放重要的資料 : 你不應該把AP的物件在資料庫中實做 : 除非你用OODB或ORDBMS : 這些資料庫就會提供定義"method"的方法 : 或者讓你mapping methods到stred procedures : ※ 引述《seagal (會長繞跑了)》之銘言： : : 這樣說也是有道理 : : 的確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)系統 : : 所以如果有任何高手能指正的話 : : 也歡迎針對我說錯的地方指正 --

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