在SQL上将过程性的、过时的CRUD代码和专有DBMS迁移到OO ORM

请原谅我长篇大论的解释，但我希望尽可能明确，希望得到尽可能多的关于我的情况的有用反馈。如果你不耐烦，可以跳到底部的问题

解释 在我目前的工作中，开发是用一种过时的语言进行的，这种语言与该语言附带的专有DBMS是硬连接的。该语言以CRUD为中心，本质上是一种美化的数据库查询/报告/更新语言，附带了一些编程特性。大多数程序都是自顶向下的过程，代码重用很少；更新一个记录通常需要同时更新许多纠缠不清的相关记录，您只需要“了解”，因为专有数据库没有固有的外键关系。如果一个表需要更新，我们通常必须grep我们的源代码并更新为该表创建/更新记录并重新编译的每个过程。我可以继续讨论其他的烦恼，但不用说，我正在寻找一种方法，尽可能多地将这种行为抽象为可重用的代码段

该语言最近添加了一些对面向对象开发的支持，我通过最近使用OO结构编写的项目向同事演示了可重用代码的好处。然而，我的项目之所以可能，是因为它是一项罕见的任务，不需要与我们的数据库交互

我一直在努力寻找一种方法，通过这种语言使用OO技术创建可重用的代码，但由于一切都是以数据库为中心的，所以我真正需要的是一种围绕表设计创建容器类的方法，将我们的大部分数据处理逻辑放入类方法中，并将N个相关表合并到一个单一类中。这让我想到了ORM框架，当然，在我工作中使用的语言中，ORM框架是不存在的

我发现，这种语言的DBMS可以与专有语言引擎同时运行SQL99引擎，它包括JDBC和ODBC驱动程序。这为我探索迁移策略打开了大门，我认为我们最终需要走这条路。由于SQL引擎与旧引擎同时运行，因此我们可以进行增量迁移，在旧代码的同时运行新代码，最终目标是在替换所有旧代码后将数据迁移到“纯”SQL DBMS

起初我读了很多书，并向我的经理推荐了Java（使用JPA2进行ORM），但我想我吓坏了他，因为他认为Java对于我们的需求来说有点重要。然后，我使用JRuby解释器（使用ActiveRecord或DataMapper for ORM）对Ruby进行了进一步的挖掘，并重新提出了Ruby，由于Rails似乎很好地适应了我们将开发转移到基于Web的前端的过程，我们正试图用我们的旧代码转移到基于Web的前端，当然，因为在需要时与Java交互的能力是一个很好的能力

问题

几乎所有我读过的书 关于ORM的工作重点是 从类结构开始，以及 创建映射数据库 结构作为第二个过程。 这是另一条路吗 （从现有数据库开始） 并将类映射到它）一个非常 奇怪的事

假设问题#1==真，怎么办 现有的ORM框架是灵活的 比如JPA2，ActiveRecord， 数据映射器等到“不完美”表 设计？我相信我们必须这样做 对现有文件进行重构 表的设计，但想知道 如果我要承担一项艰巨的任务 在我把太多时间浪费在工作上之前 努力

如果有人有更好的想法 语言+ORM，我很想听 信息技术它必须是使用JDBC准备好SQL的 或ODBC以适应我们的增量 迁移计划

如果有人有类似工作的经验，并能指出任何有用的资源（特别是书籍），我将非常感谢

我所阅读的关于ORM的几乎所有内容都集中在从类结构开始，并将映射数据库结构作为辅助进程创建。反过来（从现有数据库开始并将类映射到数据库）是一件非常奇怪的事情吗

不是真的。在处理应用程序的持久性层时，有几种方法：

• 自上而下：从对象模型和映射开始，然后从该数据派生数据库模式
• 自下而上：从数据模型（即数据库模式）开始，从表中派生对象模型和映射
• 中间输出：从映射开始，生成对象模型和表
• 中间相遇：从现有数据库模式和现有对象模型开始，开发映射以在两者之间进行映射（甚至可以引入额外的对象层并桥接现有的对象层）

自顶向下的方法是最面向对象的，但中间相遇的方法可能是最常见的

假设问题#1==真，现有的ORM框架（如JPA2、ActiveRecord、DataMapper等）对“不完美”的表设计有多大的灵活性？我相信我们将不得不对现有的表设计进行一些重构，但我想知道，在我浪费太多时间之前，我是否正在承担一项艰巨的任务

我想说，JPA不是最灵活的，它不能很好地处理异国情调或严重非规范化的模式（从OO的角度来看，结果可能很糟糕）。不通过JPA的访问也可能是一个问题。像iBatis（现在）这样的数据映射工具将为您提供