请原谅我冗长的解释,但我希望尽可能明确,希望尽可能多地获得有关我情况的有用反馈。如果您不耐烦,可以跳到底部的问题。
在我目前的工作中,开发是用一种陈旧的语言完成的,这种语言很难连接到语言附带的专有DBMS。该语言以CRUD为重点,本质上是一种美化的数据库查询/报告/更新语言,其中一些编程功能作为事后的想法加入。大多数程序都是自上而下的程序,代码重用很少;更新记录通常需要在您需要“了解”的同时更新许多纠缠的相关记录,因为专有数据库没有固有的外键关系。如果需要更新表,我们通常必须grep我们的源代码并更新为该表创建/更新记录并重新编译的每个过程。我可以继续其他烦恼,但不用说,我正在寻找一种方法来尽可能地将这种行为抽象为可重用的代码段。
该语言最近半新增了一些对面向对象开发的支持,我已经能够通过最近使用OO结构编写的项目向我的同事展示可重用代码的好处。但是,我的项目才有可能,因为这是一项罕见的任务,不需要与我们的数据库进行交互。
我一直在努力寻找使用这种语言使用OO技术创建可重用代码的方法,但由于一切都是以数据库为中心的,我真正需要的是一种围绕我们的表设计创建容器类的方法,将我们的大部分数据处理逻辑放入类方法中,并将N个相关表合并为1个奇异类。这让我想到了ORM框架,当然,我在工作中使用的语言并不存在。
我发现的原因是,该语言的DBMS可以与专有语言引擎同时运行SQL99引擎,它包含JDBC和ODBC驱动程序。这为我探索迁移策略打开了大门,我认为这是我们最终需要去的地方。由于SQL引擎与旧引擎同时运行,因此我们可以进行增量迁移,在旧代码旁边运行新代码,最终目标是在更换所有旧代码时将数据迁移到“纯”SQL DBMS
我最初做了很多阅读并向我的经理提出了Java(使用JPA2 for ORM),但我认为我害怕他,因为他认为Java对我们的需求有点重量级。然后,我使用JRuby解释器(使用ActiveRecord或DataMapper for ORM)进行了更多的挖掘和重新提议,由于Rails似乎很好地适应了我们的开发重新转移到基于Web的更好的接收效果。我们试图使用旧的cludgy代码移动到前端,当然因为如果需要,能够与Java交互是一种很好的功能。
几乎所有的阅读都有 关于ORM的一直在关注 从类结构开始,和 创建映射数据库 结构作为二次过程。 反其道而行之 (从现有数据库开始 并将类映射到它)非常 奇怪的事情呢?
假设问题#1 == true,如何 灵活的是现有的ORM框架 例如JPA2,ActiveRecord, DataMapper等到“不完美”表 设计?我相信我们必须这样做 做一些现有的重构 表设计,但想知道 如果我正在执行艰巨的任务 在我浪费太多时间之前 努力。
如果有人有更好的主意 语言+ ORM,我很想听 它。它必须使用JDBC进行SQL准备 或ODBC适合我们的增量 移民计划。
如果有任何人有类似努力的经验并且可以指出任何有用的资源(尤其是书籍),我将非常感激!
答案 0 :(得分:1)
几乎所有关于ORM的阅读都集中在从类结构开始,并将映射的数据库结构创建为辅助进程。反过来(从现有的数据库和映射类开始)是一件非常奇怪的事情吗?
不是真的。处理应用程序的持久层时有几种方法:
自上而下的方法是最面向对象的方法,但中间相遇的方法可能是最常见的方法。
假设问题#1 == true,现有的ORM框架(如JPA2,ActiveRecord,DataMapper等)对“不完美”的表格设计有多灵活?我相信我们将不得不对现有的桌面设计进行一些重构,但是在我浪费太多时间进行努力之前,我想知道我是否正在进行一项艰巨的任务。
我会说JPA不是最灵活的,它不会很好地处理异常或严重非规范化的模式(从OO的角度来看,结果可能很难看)。不通过JPA的访问也可能是个问题。像iBatis(现在mybatis)这样的数据映射工具将为您提供更大的灵活性。
如果有人对语言+ ORM有更好的想法,我很乐意听到它。它必须是SQL-ready,使用JDBC或ODBC来适应我们的增量迁移计划。
我知道RoR可以处理现有数据库,我只是不确定结果会是什么样子。但是我对RoR没有足够的经验,所以我会让专家详细说明这一点。
如果有人有类似努力的经验并且可以指出任何有用的资源(尤其是书籍),我将非常感激!
我建议浏览Scott Ambler website和他的书:
更多值得深思的话: