RE: How to make dao's / vo's more polymorphic

Paul Carr Mon, 13 Mar 2006 09:34:41 -0800

Sorry for the late reply guys....been working from home today and couldn't figure out my webmail. :-~

The Base class I'm after wouldn't hold any state at all so variable hiding wouldn't be an issue. It's simply a method of getting the polymorphic behaviour into the DAO's that I'm after.....perhaps a little explanation of my application is in order:-

I would be delighted if abator could be altered to be able to generate :-

DAO’s interfaces that all extend a common BaseDAO interface (that specifies crud methods accepting a BaseValueObject)

VO’s that all extend a common BaseVO class.(Again....no state or behaviour needs to be specified in here)

DAO’s crud methods should accept a BaseVO object and downcast it to the relevant type.

This way it’s possible to implement a fully polymorphic system. Say I’m parsing XML to insert to a database, I can use reflection to construct the relevant value object and dao based on the Tag name, and then just call dao.insert(BaseValueObject) for ANY dao.

e.g.

//parse xml into XMLObjects ( OrderXmlObject extends XMLObject )

//iterate all XMLObjects….for each

BaseVO vo = (BaseVO) Class.forName(“valueobjects.”+tagname).newInstance(); //would produce an Order value object

xmlObject.populateValueObject(vo) // and this would populate all vo fields from the xmlObject

BaseDAO dao = (BaseDAO) Classs.forName(“dao.”+tagname+”Impl”).newInstance(); // Would produce an Order DAOImpl

dao.insert(vo);

If abator could generate this way, in the future, when you add a new table to the DB, and corresponding tag in the XML you don’t need to modify any code ! Just use abator to generate a DAO and VO and that’s it !

As things stand with the current abator generated code you have to manually add the BaseDAO extension to each DAO interface, add the insert method on each DAOImpl to take a BaseVO, downcast, then call the real insert. If dealing with hundreds of tables this is very time consuming, and rather defeats the object of auto-generating the persistence layer. Plus when you change the underlying DB structure and re-generate the DAO’s / VO’s you end up having to do it all again.

What do you think ? Can it be done ? I think it would be worth doing ?

Best Regards

Paul

From: Engel, Gregory A [mailto:[EMAIL PROTECTED]
Sent: Fri 10/03/2006 17:36
To: '[email protected]'
Subject: RE: How to make dao's / vo's more polymorphic

Yes. The problem can be somewhat overcome by parsing the source file of the base class instead of introspecting

but if it's not source that you are generating it becomes a real furball because "you never know what yer

gonna get".

-----Original Message-----
From: Jeff Butler [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006 12:28 PM
To: [email protected]
Subject: Re: How to make dao's / vo's more polymorphic

Yes - that's a difficult problem on many levels. First there's the difficulty of the introspection (and what to do if there's a collision). Second there's the issue of classloading - in Eclipse it would be difficult to see the base class because the plugin has a different classloader than the Eclipse project (this can be solved in Eclipse 3.1 with OSGi buddy classloaders, but complex). Initially, I would probably take the easy way out and generate a warning message if possible. Other than that, it would be the responsibility of the user to make sure this wouldn't happen.

Jeff Butler

On 3/10/06, Engel, Gregory A <[EMAIL PROTECTED]> wrote:

One thing I ran across with this when generating code that you should be aware of (you probubly already are)

is that you have to be careful of declaring varables in the extended class with the same name as the one

in the base class.

So you have to inspect the base class before generating the code of the extended class

and only generate fields and getters/setters for the diff. Otherwise you will end up with

variable hiding which can be frustrating if later you cast to the base class.

-----Original Message-----
From: Jeff Butler [mailto:[EMAIL PROTECTED] ]

Sent: Friday, March 10, 2006 8:55 AM
To: [email protected]
Subject: Re: How to make dao's / vo's more polymorphic

Abator doesn't have support for this now - but it should be fairly simple to add. Abator would not generate these base objects, it would just assume they are there and use them - right???

Jeff Butler

On 3/10/06, Paul Carr <[EMAIL PROTECTED] > wrote:
Hi All,

Is there a way to make the DAO's and VO's generated by abator all extend
a single class or implement a common interface?

Ideally I'd like all my DAO interfaces to extend a BaseDAO and all my
value objects to extend a BaseValueObject automatically as abator
creates them ???

Best Regards
Paul.

RE: How to make dao's / vo's more polymorphic

Reply via email to