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
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.
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.
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 ]