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

[Paul Carr]

Well I’m glad I caused quite a discussion on OO vs Maps , but I guess you guys are all in the states, so I’ve got a day’s delay before I get any responses J.  I read all your mails about maps and arraylists etc, and I don’t think it really applies to my problem. I have a bunch of XMLObjects hydrated from an MDB’s message. I need to get these into the DB, but at the same time keep the design loosely coupled so that I can plug in a different kind of output writer (e.g. to another MQ queue, to a flat file, to CICS transaction gateway etc etc). So I have a Writer interface, one implementation of which is an SQLWriter, which uses the iBatis framework to insert each XMLObject to the DB. I’m starting with XMLObjects that are actually value objects, so it makes sense to use DAO’s. Now then ….abator generates the DAO’s perfectly well for me, but the OO is wrong, as all the DAO interfaces that are generated are at the top level of their own hierarchy……there is no commonality between DAO’s i.e. here is a cut down example of an abator generated DAO.   public interface ManufactureRequestDAO {     void insert(ManufactureRequest record); }   The generated dao interfaces should extend a common BaseDAO interface ( as after all , they are all DAO’s !) and have methods that accept a BaseVO……   public interface ManufactureRequestDAO extends BaseDAO {       /**      * This method was generated by Abator for iBATIS.      * This method corresponds to the database table upca.manufacture_request      *      * @abatorgenerated Wed Mar 01 12:25:19 GMT 2006      */     void insert(BaseVO record);     void insert(ManufactureRequest record); }   When abator generates the Implementation DAO’s it should add a method to downcast the passed BaseVO to the relevant type and call the genuine insert method:-   public class ManufactureRequestDAOImpl extends SqlMapDaoTemplate implements ManufactureRequestDAO {     public ManufactureRequestDAOImpl(DaoManager daoManager) {         super(daoManager);     }     public void insert(BaseVO vo) throws ClassCastException {         insert((ManufactureRequest) vo);     }     public void insert(ManufactureRequest record) {         insert("upca_manufacture_request.abatorgenerated_insert", record);     } }     Making these small changes to abator would not change ANY of the existing behaviour, everyone would still be able to use it exactly as they were doing, and more importantly the framework will continue to behave exactly as it was doing, but it would add so much more flexibility.  PLEASE DO IT ….PWEDDY PWEESE.   As for the ArrayList / Maps/ OO debate…. I’ve never used anything other than DAO’s VO’s, SO If anyone can gimme a clue where to start with the Maps method that’d be handy……BEAR IN MIND that I have to start with a collection of XMLObjects, which are actually already value objects.   Best Regards Paul Carr.     -----Original Message----- From: Clinton Begin [mailto:[EMAIL PROTECTED] Sent: 14 March 2006 03:46 To: user-java@ibatis.apache.org Subject: Re: How to make dao's / vo's more polymorphic   Don't get me wrong, iBATIS will always support Maps for those who absolutely need them.  But I'll always be very clear, about their place... :-) Cheers, Clinton On 3/13/06, Steve Biondi <[EMAIL PROTECTED]> wrote: Oddly enough it's this flexibility that has made iBATIS indispensible to us. The abstraction of "the data and behaviors are java domain objects in memory" just doesn't work for us for a host of reasons. Our tables are big and normalized, we do mainly set-based operations, work with dynamically defined relations (actual new tables, not views), rely on covered indexes for performance, use materialized views in many cases, and these aspects preclude using fully hydrated domain objects, JavaBean-based or otherwise. Sometimes its better not to ask whether maps are better than domain objects (which they clearly aren't), but rather whether domain objects are the right choice at all for your application. Sets and Lists of Maps "map" to a generic relational model quite well and sometimes offer a much better solution (no pun intended there) ;-) Using iBATIS to cleanly structure the SQL has been fantastic, much better than the usual JDBC + SQL string construction garbage we all see from time to time.   Steve   From: Clinton Begin [mailto:[EMAIL PROTECTED]] Sent: Monday, March 13, 2006 5:10 PM To: user-java@ibatis.apache.org Subject: Re: How to make dao's / vo's more polymorphic   Fair enough, I agree.  You're argument is valid against Sun's design for JavaBeans and the pattern matching approach of getters/setters -- and how they are hardly a best OOP practice (I won't get into that OOP itself isn't necessarily a best practice).... However, your argument does nothing for or against the use of Maps vs. classes as domain objects.  I will maintain that Maps are a horrible design choice for a domain model -- horrible. The solution to the challenges you present is not to use Maps, instead it is to avoid the use of JavaBeans.  Unfortunately, at this time, that also means no iBATIS (it's a JavaBeans based framework -- poo on us for listening to Sun). We're definitely adding support for both constructor injection and private field based injection of data to address this issue.  But until that time, you're better off with JavaBeans than you are with Maps -- for many, many reasons. Don't confuse (ab)using maps in Java, with the dynamic programming capabilities of languages like _javascript_ and Ruby. Cheers, Clinton On 3/13/06, Ben Munat <[EMAIL PROTECTED]> wrote: Actually, I've long been annoyed with all our frameworks forcing me to expose all my domain objects' fields via setters and getters. I've toyed with the idea of doing all my selects as maps (and my input from the UI layer too) and giving the domain objects the smarts to pick what they need out of the map. Haven't gotten around to trying it though as I'm always on a team with other people and they think I'm crazy... the "bean" paradigm is very entrenched. However, I'd say that before you go waving around the "best practices" ray gun, consider that java beans are hardly best OOP practice. b Clinton Begin wrote: > > ...and by doing that lose all of the performance, type safety, context > and compatibility of a proper domain model.  While you're at it, why not > dispense with all other best practices as well. > > Cheers,  ;-) > Clinton > > On 3/13/06, *netsql* <[EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>> wrote: > >     You can do that and more including losly coupled by using a HashMap as >     return type (return ArrayList of Maps from iBatis ) like I do. No more >     out of sync beans. > >     .V > >     Paul Carr wrote: >      > >      >             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 ??? >      > >      > > >