ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "tdev" <t...@freenet.de>
Subject Re: Suggestion: Extending Models and DAOs ?
Date Wed, 18 Jul 2007 20:40:24 GMT
Right. Exact what I meant and thought about.
Comparing it with checked in sources is I think a good 
and maybe an efficient way as long as Abator does 
not support me here. Thanks.
I will go your way as I have done so far almost.

----- Original Message ----- 
From: "Chris Lamey" <clamey@localmatters.com>
To: <user-java@ibatis.apache.org>
Sent: Wednesday, July 18, 2007 9:56 PM
Subject: Re: Suggestion: Extending Models and DAOs ?

> Hello,
> I structured some Abator generated code similar to what you're
> describing.  The Abator generated DAOs are never modified, all my custom
> code lives in their sub-classes.  I did that a long time ago when I
> first started using iBATIS, when my data model wasn't nailed down and I
> thought it'd be easier to manage change.
> Now for new projects I don't do it that way, I make mods in the Abator
> generated classes directly.  As long as everything is checked in before
> I generate new classes via Abator, I can use my usual diff tools to
> bring back any changes that I did myself.
> Also, I tend not to change the model objects themselves all that much.
> If I have to group data in some way not related to the database
> structure at all, I use classes in a different package rather than the
> models directly.
> Along with that, I'll use a service layer on top of the DAOs rather than
> put a bunch of logic in the DAOs directly.  That way, most of the biz
> logic can use the Abator DAOs without modification.  But if there's new
> sql, I'll modify the DAOs as little as possible and try to push the
> logic to the service classes.
> Cheers,
> Chris
> On Wed, 2007-07-18 at 20:55 +0200, tdev wrote:
>> Right.  Meant the Abator.
>> It is only a suggestion and meant as stated. 
>> Wanted never that someone must scratch his head therefore.
>> Maybe it's better written so
>> In short:
>> Actual:
>> General(Default)  filled          Models,DAOs,SQLMaps  A
>> package X
>> Suggest:            Specialised  empty
>> Models,DAOs,SQLMaps  B extends A       package Y

View raw message