所以我有taken over a Java Web project。该应用程序是由现在为另一家公司工作的另一位开发人员编写的。一般来说，该应用程序简单明了，设计良好，并且代码有足够的文档记录。唯一的问题是之前的开发人员决定构建自己的数据库访问库，而不是使用流行的框架。在他多年的编程生涯中，他构建了一个令人印象深刻的框架来访问任何数据库（类似于轻量级 Hiberbate）。
现在，我没有理由放弃他的代码并用更传统的 JPA 层替换数据层，因为当前代码工作得很好（尽管它很诱人！）。但我想知道是否应该使用具有新功能的更传统的框架。应用程序堆栈很简单，我可以轻松插入 Hibernate 或 JPA。所以旧页面（带有新的错误修正）将使用旧框架，而新页面将使用新框架。
然而，这种方法的一个缺点是它可能会让新开发人员感到困惑。但是，我也可以继续使用旧框架，并根据需要对其进行扩展/修复。就像我说的，它有效！
【问题讨论】：
标签： java jsp frameworks
您当然不想随心所欲地添加框架，但反之亦然，在存在可接受的替代方案时编写自己的伪框架。在我的工作中，我们必须使用 Spring 将 JPA 转换为更多的 JDBC 样式。在转换过程中，我没有删除或修改任何 JPA 代码，我只是在 JDBC 中重新编写了它。一旦我对特定方法的工作感到满意，我就会换掉实现。这让我可以零碎地完成转换，而不用从服务层下面拉出地毯，可以这么说。因此，要完全回答您的问题，只要计划迁移到其中一个框架，就可以拥有 2 个框架。
【讨论】：
艾尔迪莫，
您应该根据此类更改的投资回报来平衡纳入新框架的决定。当前项目的寿命是看待它的一种方式。
如果项目稳定且处于维护阶段，那么您不应该进行大刀阔斧的更改。
但是如果项目将继续包含新功能并继续增长，那么如果它可以增加投资回报，那么您应该考虑采用支持的框架。如果您预见到当前家庭增长框架会发生变化以支持新的需求如果其他现有框架支持这些要求，那么您有充分的理由采用它们。
但是，采用新的持久性框架会在短时间内破坏当前项目的稳定性，由于缺乏框架的团队经验而增加了错误的数量，并且还会影响开发团队的速度。
【讨论】：
“它有效” - 不要触摸！
建立一个案例来做这项工作可能是值得的——性能测试、可扩展性调查等。如果你找不到好的理由，那就把它留给当前正在使用它的项目。如果引发了足够多的 bug 归结为 DB，那么就有可能迁移到支持良好的后端。如果两者的性能都很低，那么也许使用原始 JDBC 而不是切换抽象框架。
【讨论】：
在这种情况下，我认为答案是“是”....如果您真的可以利用 Hibernate 或 JPA 拥有的功能，而遗留库没有并且 如果 你确定你不会破坏当前存在的任何东西。
通过合并 Hibernate 或 JPA，您不仅可以减轻这些开发团队的一些维护责任，而且听起来您在前进方面会更快乐。
为了跟随你的开发者，只记录你所有的改变和你背后的理由。
【讨论】：
如果它有效并且令人印象深刻，为什么要屈服于无缘无故切换到另一个框架的诱惑？除非当前框架有一些负面影响（难以维护、难以理解、无法调试等），否则我建议不要管它。
【讨论】：
这样做的真正缺点是一个框架会对数据库进行更改而另一个框架不会立即接受的风险。我在使用 NHibernate + ADO.NET 的组合之前遇到过这个问题：如果 NHibernate 缓存了某些内容，它可能会忽略 ADO.NET 的更改。
如果您可以缓解这种情况，那么这样做在技术上没有任何问题。
【讨论】：