Skip to Content.
Sympa Menu

grouper-dev - refactor the DAOs

Subject: Grouper Developers Forum

List archive

refactor the DAOs

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Grouper Dev <>
  • Subject: refactor the DAOs
  • Date: Mon, 16 Jun 2008 22:06:45 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US


Gary and I were discussing how the Grouper data layer works.

Currently it is a business object (e.g. Group) which talks to (and delegates
to) a DTO bean (e.g. GroupDTO), which talks to and lazily delegates to a DAO
bean (e.g. GroupDAO interface which is implemented by Hib3GroupDAO).

In doing hooks, there are some complications with this approach:

1. different hooks have access to different object layers, and not all object
layers have references to each other
2. when doing things like getting diffs of what has changed, the DB state of
the object needs to be stored, but this is in the DAO at the time of
Hibernate, and that particular DAO is not kept around, another is created
when needed again, so the DB state needs to be propagated: DAO -> DTO ->
Business object -> DTO -> DAO

Needless to say I am trying to simplify a little bit.

My idea was to cut out a layer or two. This would be a decent amount of
(re)work. Gary's idea is to take the bean part out of the DAO, and make it a
singleton which is only responsible for data access queries (which return
DTO's). The DTO's would hold the state of the object.

I checked it out briefly, and Gary's idea would not require a lot of code
changes, and would simplify things, so I agree this is how we should proceed.

I will do this and see how it goes. Let me know asap if anyone disagrees or
would like to discuss. These objects weren't public before and they are an
implementation detail, else I would wait for a call, but thought I would
mention it on the list. :)


Archive powered by MHonArc 2.6.16.

Top of Page