File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes JDBC and Relational Databases and the fly likes General Architecture question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC and Relational Databases
Bookmark "General Architecture question" Watch "General Architecture question" New topic

General Architecture question

Brian Smith
Ranch Hand

Joined: May 20, 2005
Posts: 63
I am designing my first JDBC project. I setting up all my Bean objects that map to my database tables, I got to thinking where the DML logic should reside. Should the "Data Beans" themselves hold the logic to connect to the datasource and do dml or should that reside in separate classes? I had another thought. If it should be in separate classes, would it be better to create "dml" classes that correspond to each of my data beans or should I create one and store the meta data needed to contruct the dml in the data bean? I know this is all pretty vague and it depends on a variety of factors I am sure. I am just wanting some thoughts of others that have been down this road already. Thanks
Jeanne Boyarsky
author & internet detective

Joined: May 26, 2003
Posts: 33111

You should definitely go for having a separate DML class. The data access layer should be a separate layer (package or class) so your system isn't as affected if you need to change the database layer.

How you go about this is up to you. Common solutions are to have a class per object or a class that knows how to write all objects.

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Brian Smith
Ranch Hand

Joined: May 20, 2005
Posts: 63
Thanks Jeanne. That was my original intent but did not know if encapsulating the data access functionality into the bean would be better or out-weigh the benefits of separation the data and data access layers.

Thanks again.
George Stoianov
Ranch Hand

Joined: Jan 15, 2006
Posts: 94
Separation is good it makes your application more resistant to change and easier to maintain but too much separation may make your code too complex with too many classes and unnecessarily complicate your design.

Where you draw the line is more an art than science, in my mind, so look at your project and see what you think may change and separate it. If you think you will benefit from separating DMLs, by reusining them and changing them and you most probably will...then separate them from the rest of the functionality - one function per class is wise.

[ May 02, 2006: Message edited by: George Stoianov ]
I agree. Here's the link:
subject: General Architecture question
It's not a secret anymore!