OOAD and RDBMS

[osubb]

I'm creating a new application that hits a RDBMS. The DB is not all that normalized and I'm not sure if they will be changing the tables later on.

Anyway I'm trying to figure out how to grab/update the data from the tables. What we did in the past was create one "TransactionDB" class that had all the connection info to JDBC, all the SQL, and returned classes modeled off the tables (really just data class, no behaviors). We would use this class to call "getDoctorInfo" which would return an object that contains all the data fields needed for program. We also called an "updateDoctorInfo" method that took the doctor data object and updated the fields.

Is there a better way to do this - any design patters I should look into? Should I separate the DB layer from the app/business layer (have an intermidiate layer that maps the table data into multiple objects?

osubb

 

[stevexff]

If you are working in Java, don't reinvent the wheel. Take a look at Hibernate.

http://www.hibernate.org

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[osubb]

Thanks for the reply. I know about hibernate. But my question was more of a general design issue. I would like to use hibernate, but I'm not sure that my manager will let me implement it for this one application. We might use it later.

Also, I'm not sure if hibernate is the way to go at this point due to our size. That would be another app to install/maintain. Do you feel that you should always go with hibernate? Is it pretty easy to install/maintain? Or should it be used where their are many apps running against the RDBMS.

I would also like more info on my original question. Is there any DB design patterns out there? Is there a general approach to designing an OOAD that uses RDBMS?

Thanks for any help.

osubb

 

[stevexff]

There is a fundamental disjoint between objects and relational databases. Writing the code to link them up can use a number of patterns (assembler, data transfer object etc.) and the coding is laborious, unrewarding, and boring to do. The creators of Object Relational mapping frameworks have all written code like this numerous times, and decided there must be a better way. They have implemented those patterns in the framework, so you don't have to.

Hibernate is free. You just download it. It is at version 3.x and hence is a mature solution, and has had thousands of hours devoted to its construction and testing. Sites all over the world use it, so it has been thoroughly field-tested. Would your solution be as good?

You are concerned that your site may be too small to afford the maintenance overhead of installing the occasional release of Hibernate. How much will it cost to maintain your bespoke persistence solution by comparison? If you are short of staff for any reason in the future, who's going to be easier to recruit - someone who's used Hibernate, or someone who can get to grips with your bespoke solution in a hurry?

There are other Object Relational mapping frameworks too. The point I am trying to make is that these things exist so that you don't have to write them from scratch.

With an OR framework in the mix, you can get on with the more interesting task of writing the objects, and let the framework take care of the persistence layer.

This wasn't supposed to be a rant, but looking back over it, it seems to come over that way...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]