ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Carr" <Paul.C...@express-gifts.co.uk>
Subject RE: How to make dao's / vo's more polymorphic
Date Mon, 13 Mar 2006 17:35:09 GMT
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.

 <Order  number=230 value=23.5/>

//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:GAEngel@Tribune.com]
Sent: Fri 10/03/2006 17:36
To: 'user-java@ibatis.apache.org'
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:jeffgbutler@gmail.com]
	Sent: Friday, March 10, 2006 12:28 PM
	To: user-java@ibatis.apache.org
	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 <GAEngel@tribune.com> 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:jeffgbutler@gmail.com ]
			
			Sent: Friday, March 10, 2006 8:55 AM
			To: user-java@ibatis.apache.org 
			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 <Paul.Carr@express-gifts.co.uk > 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.
			




Mime
View raw message