我简单回一下有关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