Our current application architecture exists of a Session Fa�ade (SLSBs) which dispatches requests to one or more local business objects (SLSBs). These business objects communicate with data access objects (DAOs) trough fine-grained interfaces. The data access objects are hand-written and contain SQL statements and calls to stored procedures (a Data Access Helper is used to abstract the low-level JDBC tasks). We would like to start using Hibernate because of the better maintainability and the reduced code complexity in the data access layer. Currently, we are investigating the different possibilities to integrate Hibernate in our application architecture. We decided to use Hibernate for every new project that will be developed in the future but we already have a lot of EJB-modules which are in development and need to be extended from time to time. Some of these modules contain lots of hand-coded DAOs and we don�t want to replace every JDBC DAO by a Hibernate DAO. Nevertheless, we would like to extend these modules with new Hibernate DAOs in stead of new JDBC DAOs. Is it possible to combine Hibernate with these hand-coded DAOs whithout duplicating the persistence logic? It�s not the intention to make POJOs for entities that are already accessible through JDBC because that would increase the maintenance cost when the DB schema changes. I expect several problems with this approach. For instance: - foreign keys to entities, represented by legacy DAOs, aren�t available as POJOs - the legacy DAOs can bypass the Hibernate cache resulting in stale data - ... Are there best practices (or frameworks) to use this mixed persistence strategy?
Well don't expect me to do the dishes! This ad has been cleaned for your convenience: