Grouper Developers Forum

[Chris Hyzer <>]

Ok, that wasn't too big of a deal, I refactored per my previous email and all 
unit tests pass.

The next step is change the data layer a little more.

Right now if the hook gets GroupDTO, it would be nice to get back to the 
Group object so that all the group members can be listed.

The Group object has two fields, the GrouperSession (who to run queries as 
for security), and the GroupDTO.  So if the GroupDTO knows the 
GrouperSession, then we can get to a Group object.  Since the GroupDTO can be 
cached (and since in OO it doesn't belong anyway), we don't want the DTO to 
have a reference to GrouperSession.  So...

The proposal is to do a ThreadLocal and inverse of control (IOC) on 
GrouperSession similar to the way the HibernateSession works with long 
running transactions, and not have the Group object keep a reference to 
GrouperSession.  We need IOC since in ThreadLocals we need to remove it when 
it is done.

Existing code would need to be modified

FROM:

GrouperSession grouperSession = GrouperSession.start(subject);
...do work...
grouperSession.stop();

TO:

GrouperSession.callbackGrouperSession(subject, new GrouperSessionHandler() {
  public Object callback(GrouperSession grouperSession) {
    ...do work...
  }});

Then at that point, the business object only has a 1 to 1 reference to DTO, 
so we could just get rid of DTO so the hooks would be very easy to use (you 
only have to worry about business object, you can list members with the 
object you receive, etc).

We could deprecate the existing session strategy, but the problem is if you 
don't close your session in the current way you are still good to go.  If you 
don't close your session with threadlocals (new way), bad things can 
happen...  so I suggest doing what we did with hibernate long running 
transactions and make the switch...  but if we want to deprecate and people 
will still compile but might or might not work, that fine too.  :)

Im not sure this is feasible, so the first thing to do is try it and see if 
there are problems...

Anyone have existing code that this would break or anyone have other 
objections?  Let me know thoughts asap.

Thanks!
Chris


> -----Original Message-----
> From: Chris Hyzer
> Sent: Monday, June 16, 2008 10:07 PM
> To: Grouper Dev
> Subject: refactor the DAOs
>
> Hey,
>
> 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.  :)
>
> Thanks,
> Chris