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 Tue, 14 Mar 2006 09:48:33 GMT
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 :-).
 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
<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