It's not a secret anymore!*
The moose likes JDBC and the fly likes General Architecture question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "General Architecture question" Watch "General Architecture question" New topic
Author

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
internet detective
Marshal

Joined: May 26, 2003
Posts: 30130
    
150

Brian,
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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, 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.

regards,
george
[ May 02, 2006: Message edited by: George Stoianov ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: General Architecture question
 
Similar Threads
domain objects as DTO's
Accessing a UI component in a managed bean
design issue in terms of J2EE
Developing Multitiered application EJB with @Remote or @Local?
Reading and writing to a JSP file using I/O