November 27th, 2011, 03:42 PM
Separating business logic, DAO, entities.
I'm an experienced programmer but I'm inexperienced in database application development. I have a relatively straightforward application I'm developing (in Java, using Hibernate for data access) and I have one question about best practices concerning the separation of business logic and database access.
Two of the objects I'm working with are Groups and Items. A Group can have many Items, an Item can only be in one Group.
I have two basic layers so far:
First, I have my entity classes, which are Group and Item bean classes. These each have their respective properties. Item contains a reference to the Group it is in, Group contains a set of the Items in it. The Group's Item set is populated by Hibernate. Item contains a foreign key from the Group table. Hibernate takes care of cascading database updates/inserts/deletes so I only need to explicitly commit new Groups - new Items are managed automatically.
Second, I have my DAO's. They are run-of-the-mill DAO objects with basic methods to look up objects by ID, and add/remove objects in the database.
My question is general but I will give a specific scenario. Given a Group, I want to find all Items in that group whose name contains a certain string.
I have three ways of doing this:
1. I can add a method to my ItemDAO to retrieve a list of items given a Group and a name string. Then, in my application, I would do this (pseudo-ish code):
List<Item> items = itemDAO.findByGroupAndName(theGroup, theNameString);
Disadvantages: DAO calls in application; DAO instance must be available (they aren't static/singletons, I use factories to access).
2. I can do #1, but then add a method to my Group entity class that retrieves the list of items in that group using the ItemDAO. Then, in my application, I would not make DAO calls to find the items, I would do:
Advantages: Item finding is a method of Group. Application does not call DAO.
// in the group:
return getItemDAO().findByGroupAndName(this, theNameString);
// elsewhere, in the application:
List<Item> items = theGroup.findItemsByName(theNameString);
Disadvantages: DAO calls from entity layer. DAO instance must be available to Group entity.
3. I can add a method to Group that searches the Group's Item set for matching Items, plain-old-Java style.
Advantages: Item finding is a method of group. Item finding logic does not involve any DAO or data-access specific calls. Works with Groups that are not persistent. Logic is independent of database - entity classes do not depend on DAO.
Disadvantages: All Items must be loaded from database for persistent group (this happens automatically, lazily, managed by Hibernate). In this small application this is unlikely to be an issue. In larger applications, I don't know.
What is the best option here in terms of not digging myself into a hole down the road, and keeping my code maintainable, extendable, and reusable?
I don't know if the advantages and disadvantages I listed above are actually advantages and disadvantages, so put a question mark after all of those.
Edit: Removed some contributions that my cat made to this post while I wasn't looking.
Last edited by peenie; November 27th, 2011 at 03:55 PM.
OMG RAVER CHICKS!!
On a related note: C/C++ Programming Tutorials
"Science is based on reality staying the same, and Nature ignores what humans vote upon." -- Bill Beaty
"Three litres of sherry up the butt can only be described as astounding." -- Darwin Awards
November 30th, 2011, 06:03 AM
I don't know java but it is normal for business objects to have access to the DAO. Therefore I would go for option 2.
Option 1 would be a no as you're accessing the DAO from the GUI level.
Don't like the idea of 3.