Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question regarding refactoring to ORM and DAO/Entities

 
Rj Ewing
Ranch Hand
Posts: 93
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, I have a couple of questions about migrating to an ORM and layers such as DAO.

In our current application, I am looking at improving our persistence code. We are currently using JDBC. The way it is currently designed (sql Connection a property in the DBUtil class), it is easy for people to forget to close connections. An easy fix would be to remove the Connection property from the DBUtil class and use the getConnection method to return a new Connection. Then the Connection would be a local variable and it would be easier to remember to close it. However I'm thinking that maybe there is a better solution and am curious if moving to an ORM would be advantageous.

Our DB is fairly simple, only 10 table, we the majority of the read/write queries to just 3 tables and 1 "mapping" table. Table A has a one-many relationship with table B. Table B has a one-many relationship with table C, however the relationship isn't required and entries into table C can exist on their own (Not being related to table B). 95% of the time, Table C is related to table B.

I have read that ORM's are good for complex schemas, and can potentially improve queries. I am doing the majority of the programming now and am definitely not an SQL expert, but can write basic SQL, so I do think we would get some performance gains. I do have some experience using python Django's ORM, so the concept isn't too foreign to me. Also, we will need to access the same db from multiple applications in the near future.

Question 1: Would an ORM would be the best choice given our fairly simple db schema. Maybe just refactoring our current DBUtil class and utilizing something like apache commons DbUtils to eliminate some boilerplate code would make more sense.

Question 2: When writing entity classes that resemble a table, where is the appropriate place to put derived properties? Is it better to not use them and just have the code in the business logic? Or is it okay to have methods in the Entity that calculate and set derived properties?

Any help is appreciated.
 
Rj Ewing
Ranch Hand
Posts: 93
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
any comments?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic