在同一个项目中有两个框架可以吗？

Question

所以我有taken over a Java Web project。该应用程序由另一位现在为另一家公司工作的开发人员编写。一般来说，应用程序很简单，设计得很好，代码也足够记录。唯一的问题是，之前的开发人员决定构建自己的数据库访问库，而不是使用流行的框架。在他的编程生涯中，他构建了一个令人印象深刻的框架来访问任何数据库（类似于轻量级的Hiberbate）。

现在，我没有理由抛弃他的代码并用更传统的JPA层替换数据层，因为当前的代码工作正常（虽然它很诱人！）。但我想知道是否应该使用更具传统性的新功能框架。应用程序堆栈很简单，我可以轻松地插入Hibernate或JPA。所以旧页面（带有新的错误修正）将使用旧框架，新页面将使用新框架。

然而，这种方法的一个缺点是它会让新开发人员感到困惑。但是，我也可以继续使用旧框架，根据需要扩展/修复它。就像我说的，它有效！

Answer 1

你当然不想随心所欲地添加框架，但反之亦然，当存在可接受的替代方案时编写自己的伪框架。在我的工作中，我们不得不使用Spring从JPA转换为更多JDBC风格。在转换过程中，我没有删除或修改任何JPA代码，我只是在JDBC中重写它。一旦我觉得特定方法有效，我就会换掉实现。这让我可以将转换过来，而不是从服务层下拉出地毯，可以这么说。因此，要完全回答您的问题，只要计划要迁移到其中一个，就可以拥有2个框架。

Answer 2

Eldimo，

您应该根据此类变更的投资回报来平衡合并新框架的决策。目前项目的长寿是看待它的一种方式。

如果项目稳定且处于维护阶段，则不应进行大幅更改。

但是，如果项目将继续包含新功能并继续增长，那么您应该考虑采用支持的框架，如果它增加投资回报。如果您预见到当前的本地增长框架的变化，以支持新的要求如果这些要求得到其他现有框架的支持，那么您有充分的理由采用它们。

然而，采用新的持久性框架会在短时间内破坏当前项目的稳定性，由于缺乏团队的团队经验而增加了错误的数量，并且还会影响开发团队的速度。

Answer 3

“它有效” - 不要碰！

建立执行此项工作的案例可能是值得的 - 性能测试，可伸缩性调查等。如果您没有找到合理的理由，请将其留给当前正在使用它的项目。如果引发了足够的错误归结为数据库，那么就有一种情况可以迁移到支持良好的后端。如果两者的性能都很低，那么原始JDBC可能是一种方法而不是切换抽象框架。

Answer 4

在这种情况下，我认为答案是“是”.... 如果你真的可以利用Hibernate或JPA拥有的遗留库不具备的功能和 if 您确定不会破坏当前存在的任何内容。

通过合并Hibernate或JPA，您不仅要卸载这些开发团队的一些维护责任，而且听起来您在前进方面会更快乐。

为了跟随你的开发人员，请记录所有更改及其背后的推理。

Answer 5

如果它有效且令人印象深刻，为什么要屈服于无缘无故地切换到另一个框架的诱惑？除非当前的框架有一些负面因素（难以维护，难以理解，无法调试等），否则我会说不管它。

Answer 6

执行此类操作的真正缺点是，一个框架将对数据库进行更改而另一个框架无法立即获取的风险。在使用NHibernate + ADO.NET的组合之前我已经遇到过这个问题：如果NHibernate缓存了某些东西，它可能会忽略ADO.NET的变化。

如果你可以减轻这种影响，那么在这方面没有任何技术上的错误。