Unruly Rambling - Spring and Hibernate, Simplify the DAO layer

To make things worse, what if you want to swap out your JDBC DAO classes for ones that use a persistence framework like Hibernate. Hibernate catches my eye because I immensely dislike writing gobs of SQL. For a Java programmer, Hibernate offers a much more natural way of persisting objects. Instead of writing JDBC code, hibernate allows me to deal with POJO's and persist them for me. The bulk of my work lies in maintaing OR Mapping files. With hibernate, developers working outside the data access layer will not know which classes are persisted and which are not since the POJO's do not extend or implement anything. So lets use hibernate in our application them. Unfortunately for us, our make believe application has DataSource's floating around in method signatures. Since hibernate uses a SessionFactory object instead of a data source, mass code changes will need to be made to make the transition. Obviously Hibernate knows about data sources under the covers but client code is not aware of that. For those of you thinking of a "find and replace" engineering solution, I hope I never get the opportunity to work with you :) The find and replace approach is similar to loosening a rusty bolt with a pair of pliers. It might work once, maybe twice, but over time your bolt's integrity will be compromised and in need of a replacement. The same is true for your code. It will start to deteriorate over time. I've seen this over and over and over again! Heck I may have even participated in this kind of macro program

Highlighted by rraghur

To make things worse, what if you want to swap out your JDBC DAO classes for ones that use a persistence framework like Hibernate. Hibernate catches my eye because > I immensely dislike writing gobs of SQL. For a Java programmer, Hibernate offers a much more natural way of persisting objects. Instead of writing JDBC code, > hibernate allows me to deal with POJO's and persist them for me. The bulk of my work lies in maintaing OR Mapping files. With hibernate, developers working outside the data access layer > will not know which classes are persisted and which are not since the POJO's do not extend or implement anything. So lets use hibernate in our application them. Unfortunately for us, our make believe application has DataSource's floating around in method signatures. > Since hibernate uses a SessionFactory object instead of a data source, mass code changes will need to be made to make the transition. > Obviously Hibernate knows about data sources under the covers but client code is not aware of that. For those of you thinking of > a "find and replace" engineering solution, I hope I never get the opportunity to work with you :) The find and replace approach is similar > to loosening a rusty bolt with a pair of pliers. It might work once, maybe twice, but over time your bolt's integrity will be compromised and in need of a replacement. > The same is true for your code. It will start to deteriorate over time. I've seen this over and over and over again! > Heck I may have even participated in this kind of macro program >ming in

Highlighted by rraghur

which

Highlighted by cvleung