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

您当然不想一时兴起地添加框架,但反过来也不好,在存在可接受的替代方案时编写自己的psuedo框架。在我的工作中,我们必须使用Spring将JPA转换成更具JDBC风格的格式。在转换过程中,我没有删除或修改任何JPA代码,只是在JDBC中重新编写了它。一旦我对特定方法的工作感到满意,我就会交换实现。这让我可以在转换过程中分秒必争,不用把地毯从服务层下面拉出来。因此,为了完全回答您的问题,只要计划迁移到其中一个框架,就可以有两个框架。

埃尔迪莫,

如果项目是稳定的,并且处于维护阶段,那么您不应该进行剧烈的更改。

但是,如果项目将继续合并新的特征并继续增长,那么如果增加投资回报,就应该考虑采用支持的框架。如果您预见到当前家庭成长框架中的变化以支持新的需求,并且如果这些需求得到其他现有框架的支持,那你就有充分的理由收养他们了。

然而,采用新的持久性框架将在短时间内破坏当前项目的稳定性,由于缺乏使用该框架的团队经验,会增加bug的数量,还可能影响开发团队的速度。

为完成这项工作建立一个案例可能是值得的——性能测试、可伸缩性调查等。如果您没有找到好的理由,就让它用于当前正在使用它的项目。如果出现了足够多的bug,可以归结为DB,那么就有理由迁移到支持良好的后端。如果两者的性能都很低,那么可能使用原始JDBC,而不是切换抽象框架。

如果 如果

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

为了后面的开发人员,只需记录所有更改及其背后的推理 .

如果它有效并且令人印象深刻,为什么要屈服于毫无理由地切换到另一个框架的诱惑呢?除非当前的框架有一些缺点(难以维护、难以理解、无法调试等),否则我建议不要管它。

这样做的真正缺点是,一个框架可能会对数据库进行更改,而另一个框架不会立即进行更改。在使用NHibernate+ADO.NET组合之前,我遇到过这样的情况:如果NHibernate缓存了某些内容,它可能会忽略ADO.NET更改。

如果你能缓解这种情况,那么这样做在技术上没有什么错。