You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by tdev <td...@freenet.de> on 2007/07/17 20:44:57 UTC
Suggestion: Extending Models and DAOs ?
Would be nice when generating Models and DAOs A
there could also be generated Models and DAOs B that extends the Models and DAOs A
into an different package. The same with extra sqlmaps
In short:
General(Default) Models,DAOs,SQLMaps package A
Specialised Models,DAOs,SQLMaps package B extends A
So I need not to worry about merge etc. if I put some further code into it, own sqls,..
although it is said that the eclipse plugin does java merge, and xml is merged always.
Re: Suggestion: Extending Models and DAOs ?
Posted by tdev <td...@freenet.de>.
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" <cl...@localmatters.com>
To: <us...@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
>>
>>
>
Re: Suggestion: Extending Models and DAOs ?
Posted by Chris Lamey <cl...@localmatters.com>.
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
>
>
Re: Suggestion: Extending Models and DAOs ?
Posted by tdev <td...@freenet.de>.
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
Re: Suggestion: Extending Models and DAOs ?
Posted by rh...@mac.com.
Sounds like he's asking about abator, but other than that, I'm
scratching my head.
--R
On Jul 17, 2007, at 2:57 PM, Jeff Butler wrote:
> Currently, you can specify a root class for generated model
> objects, and a root interface for generated DAO interfaces. Will
> this work for you?
>
> I'm not sure I understand what you're asking.
>
> Jeff Butler
>
>
>
> On 7/17/07, tdev <td...@freenet.de> wrote:
> Would be nice when generating Models and DAOs A
> there could also be generated Models and DAOs B that extends the
> Models and DAOs A
> into an different package. The same with extra sqlmaps
>
> In short:
> General(Default) Models,DAOs,SQLMaps package A
> Specialised Models,DAOs,SQLMaps package B
> extends A
>
> So I need not to worry about merge etc. if I put some further code
> into it, own sqls,..
> although it is said that the eclipse plugin does java merge, and
> xml is merged always.
>
>
>
>
Re: Suggestion: Extending Models and DAOs ?
Posted by Jeff Butler <je...@gmail.com>.
Currently, you can specify a root class for generated model objects, and a
root interface for generated DAO interfaces. Will this work for you?
I'm not sure I understand what you're asking.
Jeff Butler
On 7/17/07, tdev <td...@freenet.de> wrote:
>
> Would be nice when generating Models and DAOs A
> there could also be generated Models and DAOs B that extends the Models
> and DAOs A
> into an different package. The same with extra sqlmaps
>
> In short:
> General(Default) Models,DAOs,SQLMaps package A
> Specialised Models,DAOs,SQLMaps package B extends
> A
>
> So I need not to worry about merge etc. if I put some further code into
> it, own sqls,..
> although it is said that the eclipse plugin does java merge, and xml is
> merged always.
>
>
>
>