Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm
Received-SPF: pass (hermes.apache.org: domain of clinton.begin@gmail.com
 designates 64.233.184.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=F0OiXyavnH9K3sVonIdyK7j6MVHmXnta3bXOcMajD6VI8U2Bo6cr4OiSqSXsq29Ii9Ohp2tx3TCEEQZbsr8efnfYKXFseSi6vwJayUc2a6eUx6/iHdoN5htSlRBd09yBz1yZTyFRQsXQQZm0Ehr1JxPUU4yYMAaE7exbDqoremA=
Message-ID: <16178eb10501241304798865f6@mail.gmail.com>
Date: Mon, 24 Jan 2005 14:04:42 -0700
From: Clinton Begin <clinton.begin@gmail.com>
Reply-To: cbegin@ibatis.com
To: ibatis-user-java@incubator.apache.org
Subject: Re: java.util.HashMap as resultClass
In-Reply-To: <20050124204427.71364.qmail@web53104.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <1106592527.22780.88.camel@standing-cow.home>
	 <20050124204427.71364.qmail@web53104.mail.yahoo.com>

Pascal,

Another approach is to use a wrapper class at your presentation layer.
 After all, this is a presentation layer problem, that is probably
best solved in the presentation layer -- not in the persistence layer.

By aliasing your columns to ID and Value, you've made a change to your
persistence for the sake of a presentation requirement.

Here's my recommendation:

1) Use a real domain model.  Avoid Maps.  Create a real class that
represents your domain.  In this case it looks like a Product class or
something (with properties such as  SKU, Description etc.)

2) Map that class with iBATIS properly, using a real parameter class
and result class, with columns mapped to the JavaBean properties.

3) Use that domain object throughout your application.  When a
requirement such as a droplist manifests itself, use a wrapper class
to manage special behavior.  For example, given a Product class, you
could have a ProductDropListItem that knows how to provide the
appropriate identifier and value to the drop list.

Don't worry about having to make a matching DropListItem for each
class.  It's very easy to make a generic one that will work with any
domain class (passed into the constructor).  E.g. new DropListItem
(aProduct).

This keeps presentation layer problems out of the persistence layer. 
It's also pretty easy to implement.

Cheers,
Clinton  

On Mon, 24 Jan 2005 12:44:27 -0800 (PST), Prashanth Sukumaran
<prashanthsukumaran@yahoo.com> wrote:
> Hi Pascal,
> 
> I think i understand what Brandon is trying to say. He is talking about using the right pattern
> for the kind of job you are trying to achieve.
> 
> If my guess is right. Looks like you trying to do this for your dropdowns.  I do it this way and i
> feel it is much cleaner this way.
> 
> public interface ValueObject{
> 
>     /**
>      * Gets the iD attribute of the KeyValueObject object
>      *
>      * @return   The iD value
>      */
>     String getID();
> 
>     /**
>      * Gets the value attribute of the KeyValueObject object
>      *
>      * @return   The value value
>      */
>     String getValue();
> 
>   /**
>    * This method returns sort field
>    *
>    *
>    * @return value of sort field
>      */
>     public Object getSortFieldValue();
> }
> 
> All Objects that you are using for Dropdowns will extend the ValueObject, and they will implement
> the three methods.  In your case getID() will return SKU, getValue will return Description.  and
> for the getSortFieldValue() have an empty implementation.  This way the bean can be used for other
> things and also used for dropdowns.
> 
> For the dropdowns have a common method that handles them or even struts has the LabelValue bean.
> 
> Rgds
> Prashanth.
> 
> 
> --- Pascal DeMilly <list.ibatis@newgenesys.com> wrote:
> 
> > Well. It seems logical to me. Why would iBatis go into great length at
> > trying to map result in the SqlMap file then if it was not to limit the
> > knowledge of your database to that XML file. The dependency have to stop
> > somewhere and it seems to me the SqlMap file is the place where it
> > should stop. The DAO implementation classes should only know about the
> > iBatis map id and its expected POJO results not how your database
> > columns are named or it seems to me.
> >
> > Anyway, in my case while this solve one of my problem, queryForMap is
> > still not as efficient as it could be since it relies on queryForList.
> > So basically it is building two list. One with each element being a Map
> > of column name/value, then another map of only values. Would it be more
> > efficient to rewrite queryForMap to use a RowHandler?
> >
> >
> >
> > On Mon, 2005-01-24 at 10:15, Brandon Goodin wrote:
> > > Why is it a problem to have a code dependency in an "implementation"
> > > class? It is suppossed to be aware of IBatis SQLMap semantics. You
> > > interface over your DAO class should hide the specifics of your
> > > implementation code within your Dao.
> > >
> > > Brandon
> > >
> > >
> > >
> > >
> > > On Mon, 24 Jan 2005 09:22:49 -0800, Pascal DeMilly
> > > <list.ibatis@newgenesys.com> wrote:
> > > > Thanks Larry,
> > > >
> > > > I tried it and it works. However this still leave some dependencies in
> > > > my DAO code as I have to specify the column names there as in:
> > > >
> > > > return getSqlMapClientTemplate().queryForMap("getItemNameMap", null, "SKU", "Description");
> > > >
> > > > How will you do about moving that code into the SqlMap. Should I create
> > > > a custom resultMap with key/value as properties and refer to it in my
> > > > DAO code?
> > > >
> > > > I am going to give it a try and see what happened.
> > > >
> > > > Thanks for you help.
> > > >
> > > > Pascal
> > > >
> > > > On Mon, 2005-01-24 at 08:44, Larry Meadors wrote:
> > > > > Try executeQueryForMap() instead.
> > > > >
> > > > >
> > > > > On Mon, 24 Jan 2005 08:42:25 -0800, Pascal DeMilly
> > > > > <list.ibatis@newgenesys.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I would like to retrieve a Map with whose key is the 1st column of my
> > > > > > query and the value is the 2nd column. For example right now I do:
> > > > > >
> > > > > > <select id="getItemNameMap" resultClass="java.util.HashMap">
> > > > > >         select SKU, Description from Items
> > > > > > </select>
> > > > > >
> > > > > > However this returns a list of maps with the key being the column name
> > > > > > and the value the column value which seems wasteful in term of space (I
> > > > > > am using remoting to retrieve that info).
> > > > > >
> > > > > > I currently solve it by using a custom rowHandler in my DAO as follow:
> > > > > >
> > > > > >     public Map getItemNames () throws DataAccessException {
> > > > > >         final KeyValueHandler rowHandler = new KeyValueHandler ();
> > > > > >         getSqlMapClientTemplate().queryWithRowHandler("getItemNameMap", null,
> > rowHandler);
> > > > > >         return rowHandler.getMap();
> > > > > >     }
> > > > > >
> > > > > >     private class KeyValueHandler implements RowHandler {
> > > > > >         final Map map = new HashMap ();
> > > > > >
> > > > > >         public void handleRow(Object valueObject) {
> > > > > >             final Map row = (Map) valueObject;
> > > > > >             map.put (row.get("SKU"), row.get("Description"));
> > > > > >         }
> > > > > >
> > > > > >         public Map getMap () {
> > > > > >             return map;
> > > > > >         }
> > > > > >
> > > > > >     }
> > > > > >
> > > > > > But I would like to move possibly that code out of my DAO code and into
> > > > > > iBatis SqlMap file.
> > > > > >
> > > > > > How could I do that
> > > > > >
> > > > > > TIA
> > > > > >
> > > > > > Pascal
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>