Is it OK to have two frameworks in the same project?

Question

So I have taken over a Java Web project. The application was written by another developer who now works for another company. Generally speaking, the application is straightforward, well designed and the code is documented enough. The only issue is that the previous developer decided to built his own database access library instead of using a popular framework. Over the years of his programming career he has build an impressive framework to access any database (something similar to a lightweight Hiberbate).

Now, I have no reason to throw away his code and replace the data layer with a more conventional JPA layer since the current code work just fine (although it is tempting!). But I was wondering if I should use a more conventional framework with new features. The application stack is straightforward and I could easily plug Hibernate or JPA. So old pages (with new bugfixes) would use the old framework, and the new page would use the new framework.

One of the drawback of this approach however is that it can get confusing to new developer. However, I can also continue to use the old framework, expanding/fixing it as necessary. Like I said, it works!

Answer 1

The real drawback to doing something like this is the risk that one framework will make changes to the database that the other framework will not pick up immediately. I've run into this before using a combination of NHibernate + ADO.NET: if NHibernate has cached something, it may ignore ADO.NET changes.

If you can mitigate that, there's nothing technically wrong with doing this.

Answer 2

You certainly don't want to add frameworks at a whim, but the opposite is also bad, writing your own psuedo-framework when an acceptable alternative exists. In my job, we had to a do a conversion from JPA to a more JDBC style using Spring. During the conversion, I didn't delete or modify any of the JPA code, I simply re-wrote it in JDBC. Once I was comfortable that particular method worked, I would swap out the implementation. This allowed me to piece-meal the conversion over, without pulling the rug out from under the service layer, so to speak. So to fully answer your question, it is okay to have 2 frameworks as long as the plan is to migrate to one or the other.

Answer 3

"it works" - don't touch!

It might be worthwhile building up a case for doing this work - performance tests, scalability investigations, etc. If you find no good reason, leave it be for projects that are currently using it. If enough bugs are raised that boil down to the DB, then there is a case there for migration to a well supported backend. If performance is low for both, then maybe raw JDBC is the way to go rather than switching abstraction frameworks.

Answer 4

In this case, I think the answer is "yes"....if you truly can make use of the features Hibernate or JPA possess that the legacy library does not and if you're certain you won't be breaking anything that currently exists.

By incorporating either Hibernate or JPA not only are you offloading some of the maintenance responsibility on those development teams, but it sounds like you'll be happier in terms of moving forward.

Just document all your changes and your reasoning behind them, for the sake of the developer who follows you.

Answer 5

If it works and is impressive, why give in to the temptation to switch to another framework for no reason? Unless the current framework has some negatives (hard to maintain, hard to understand, impossible to debug etc), I say leave it alone.

Answer 6

Eldimo,

You should balance the decision to incorporate a new framework based on the return of investment of such change. The longevity of the current project is one way to look at it.

If the project is stable and on maintenance phase then you shouldn't make drastic changes.

But if the project will continue to incorporate new features and continue to grow, then you should consider adopting a supported framework if it increases the return of investment.If you foresee changes in the current home grow framework in order to support new requirements and if those requirements are supported by other existing frameworks, then you have a strong reason to adopt them.

However, the adoption of a new persistence framework will destabilize the current project for a short period of time, increasing the volume of bugs due to the lack of team experience with the framework and can also affect the velocity of the development team.