将自定义持久层迁移到hibernate3

Question

因此，很快，我将成为一个迁移的一部分，它将把一个家庭滚动的持久性层(大概是任何好的、流行的ORM)迁移到hibernate3。但是，在发生这种迁移的同时，开发人员将致力于在当前的持久层之上实现新的业务逻辑，从而反对迁移！是否有人对如何最好地管理大约1 1MLOC的迁移有建议？

我有一些初步的想法，但我想要输入。

最初，hibernate迁移可能需要是主要开发线的一个分支，专门用于将当前系统转换为使用hibernate。在某个时候，开发应该切换到hibernate分支，或者hibernate分支应该合并回主开发线。一些开发人员可能需要非常漂亮--只专注于迁移任务--尽管每个开发人员都可能有特殊的业务知识，这是完成新逻辑所必需的。

还有其他人完成过这么大的任务吗？我在想，也许可以给每个开发人员某种数量的配给，比如80/20，60/40用于新逻辑和迁移工作的时间。通过这种方式，每个开发人员都可以拥有自己的代码域，并且所有开发人员都将暴露于新的范例中，以防止开发人员在所有迁移工作中突然中断工作，突然暴露于hibernate中。

那么，哪一个可能更好呢？

--专门负责迁移的开发人员的核心单元

或

为迁移在所有开发人员之间分配开发

其中哪一个会更好，为什么？

Answer 1

我在过去做过这样的迁移，情况非常相似:这是一个巨大的关键项目(迁移时有120多个开发人员)，该项目使用了自己的持久性框架(不是ORM，更多的是与JDBC非常接近的数据映射器)，我们在开始的一年后，在构建阶段的中间引入了Hibernate，没有停止开发。

以下是我们是如何做到的：

• 我们专门派出了一个swat团队(在3周内有10人)来启动迁移
• ，我们在一个单独的分支中完成了这一工作，我们不能干扰构建团队
• ，我们逻辑上是从对象图的最深处开始的：(所有的“参考数据”，比如客户、银行账户、金融工具等等，也就是大部分读取到处使用的数据)。我们为所有未经过足够测试的DAO编写了测试，我们映射了业务对象，我们使用Hibernate API和HQL

重写了DAO方法

​

在一些极其关键的部分上，我们在一周结束时合并了代码，做了所有可能的回归测试(0回归：)，我们训练了建设团队，并创建了一些新的开发规则

​

而且起作用了。