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 > >
