JPA Vs SpringJDBC
Recently I conducted many interviews for my employer, one 8-9 yrs exp candidate asked me what data access object layer do we use in our project. I was thinking a bit as , like they do with persistence - polyglot persistence, we maintain different DAO technologies - JPA, proprietary JDBC, JDO, Spring JDBC. you cannot say which one is the best. It depends on the context but definitely having so many things for performing dataaccess is not advisable.
In this topic I will try to explore the JPA and Spring JDBC.
Spring is a life savior, it's template concept reduces the boilerplate code but still the jdbc template comes with baggages - row mapper, SQL, parameters etc. If you have good knowledge of database schema, you want to execute stored procedure, you want more handle on your code to access the db. Then go for Spring, you can debug easily and have control on your DTO.
If you need to abstract away the SQL, hide complexity, write less code, dont need to execute the stored procedures then go for JPA. It will expose the domain model to your entities. But debugging is really difficult.
In this topic I will try to explore the JPA and Spring JDBC.
Spring is a life savior, it's template concept reduces the boilerplate code but still the jdbc template comes with baggages - row mapper, SQL, parameters etc. If you have good knowledge of database schema, you want to execute stored procedure, you want more handle on your code to access the db. Then go for Spring, you can debug easily and have control on your DTO.
If you need to abstract away the SQL, hide complexity, write less code, dont need to execute the stored procedures then go for JPA. It will expose the domain model to your entities. But debugging is really difficult.
why do you need to debug persistency layer ? The tuple data(s) is all you need. This can be done with db dependent tests / fitnesse. With that said, I oveeride the toString() method (though not recommended) which gives me the tuple object info. You could spit it out in debug info.. one way to increase supportability
ReplyDeleteGood question...let me explain...one example is you are calling a stored proc and sporadically it is returning null for few fields, when you execute the the stored proc directly then it works fine...thus you need to debug to find the interaction of your dao layer with the snow layer...Fitnesse is arguable, many people think that fitnesse is wastage of time, as you keep updating the failing fixtures as you go, maintenance cost of fitnesse is huge, instead simple out of container tests help... still you need to debug to see what is going wrong.. if you use jpa the debugging becomes tough
DeleteWell with your example, it sounds you configured your ORM incorrectly / conditionally. Your SP testing should be in the RDBMS layer. If your Tuple Object is returning data incorrect sproadiacally, the toString() method would help. I agree to the maintainability of Fitnesse but it helps in scenario testing. You could go the slow test route too to test your sporadic conditions - but when you say you want to debug ORM layer - that is debugging framework code. If have to debug it then probably your design is wrong.
DeleteI was referring to spring jdbc for sp debugging. Jpa usually doesn't need stored procs. You are right configuration issues crop up in production for example you tested thoroughly in tomcat or GlassFish but when you deploy in JBoss or WAS your code starts behaving weirdly as jpa needs container specific metadata... but for spring jdbc it is WORA, you ain't need to change anything ( provided you are doing jee:lookup and JTA)... so in this context you need to invedtigate... fitnesse or slow test cannot help...specifically jpa jpa parameters...I had hard time with JPA and atomikos, it worked fine in tomcat but failed in GlassFish... had to change a lot of code after debugging...yes the hibernate internals debugging...
ReplyDeleteCode means the persistence.xml
ReplyDelete