ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: How to make dao's / vo's more polymorphic
Date Tue, 14 Mar 2006 17:30:05 GMT
If you want to hear a guaranteed lie, then ask an open source committer the
"when" question. :-)

Seriously, I can probably get it finished over the weekend.  I have to work
for a living until then.

Jeff Butler


On 3/14/06, Paul Carr <Paul.Carr@express-gifts.co.uk> wrote:
>
>  GOOD MAN JEFF !
>
>
>
> I can downcast before I call insert easy enough.
>
> When do you figure this will be available ?  (got a project going live
> early May)
>
>
>
> Cheers
>
> Paul.
>
>
>
> -----Original Message-----
> *From:* Jeff Butler [mailto:jeffgbutler@gmail.com]
> *Sent**:* 14 March 2006 16:32
> *To:* user-java@ibatis.apache.org
> *Subject:* Re: How to make dao's / vo's more polymorphic
>
>
>
> I've been without power for a couple of days due to a bad storm, so I've
> missed some of the debate too.  I'm going to sidestep the whole "OOP best
> practices" talk (sound and fury).
>
>
>
> As for Abator, I can make the change to allow you to specify a base class
> for the domain objects, and a base interface for the DAO interface.  I
> really don't care for the downcasting thing - could you live without it (do
> the downcast somewhere else)?  BTW - downcasting is a sign of a
> non-polymorphic system, so I don't think that's exactly what you mean:
> polymorphism implies no casting.
>
>
>
> You could also write your own DAO generator that did the downcast.
>
>
>
> Jeff Butler
>
>
>
>
>
> On 3/14/06, *Paul Carr* <Paul.Carr@express-gifts.co.uk> wrote:
>
> 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: clinton.begin@gmail.com]
>
> *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* < SteveB@schemalogic.com> 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:clinton.begin@gmail.com]
> *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* < bent@munat.com> 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* < netsql@roomity.com <mailto: netsql@roomity.com>>
> 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 ???
> >      >
> >      >
> >
> >
>
>
>
>
>
>
>

Mime
View raw message