If all my sql is in xml, do I gain that much (assuming unit tests) using Mapper objects as well?

[Rick R <ri...@gmail.com>]

This probably has been brought up before, but a quick search on nabble
didn't return anything that useful at the moment...

Our plan is to have ALL sql in the mapper xml files (not annotations.) It
'seems' like the only real benefit we'd then get out of also providing a
corresponding mapper object is for IDE support and catching of any invalid
calls early on (and maybe refactoring is slightly cleaner but that's
debatable.)  But assuming we have a unit test for every mapper sql command
in our service layer, is there anything else I miss by skipping the whole
creation of mapper objects and simply going after the sql the old way...
session.update("fooBar.updateEmployee", obj) ? (I read pages 53/54 of the
guide and nothing jumped out at me as a huge gain in our case using Mapper
classes.)

I just don't want to be overlooking anything.

-- 
Rick R

Re: If all my sql is in xml, do I gain that much (assuming unit tests) using Mapper objects as well?

[Clinton Begin <cl...@gmail.com>]

To me, it's about readability.  I think there's an example in the
documentation to this point...

Clinton

On Wed, Feb 17, 2010 at 2:28 PM, Rick R <ri...@gmail.com> wrote:

>
>
> On Wed, Feb 17, 2010 at 4:09 PM, Jeff Butler <je...@gmail.com>wrote:
>
>> In my case, it's a bit less code:
>>
>> Mapper interface:
>> List<MyObject> getByCompoundKey(@Param("id1") Integer id1,
>> @Param("id2") Integer id2);
>>
>
>
> Ah I see. That's an excellent point!  I hadn't thought of that. In our case
> 99% of the parms will be coming in through a single pojo type being passed
> to the query, but I can totally see how the above would be extremely useful.
>
>

Re: If all my sql is in xml, do I gain that much (assuming unit tests) using Mapper objects as well?

[Rick R <ri...@gmail.com>]

On Wed, Feb 17, 2010 at 4:09 PM, Jeff Butler <je...@gmail.com> wrote:

> In my case, it's a bit less code:
>
> Mapper interface:
> List<MyObject> getByCompoundKey(@Param("id1") Integer id1,
> @Param("id2") Integer id2);
>


Ah I see. That's an excellent point!  I hadn't thought of that. In our case
99% of the parms will be coming in through a single pojo type being passed
to the query, but I can totally see how the above would be extremely useful.

Re: If all my sql is in xml, do I gain that much (assuming unit tests) using Mapper objects as well?

[Jeff Butler <je...@gmail.com>]

In my case, it's a bit less code:

Mapper interface:
List<MyObject> getByCompoundKey(@Param("id1") Integer id1,
@Param("id2") Integer id2);

versus

Method in some class:
@SupressWarnings("unchecked")
List<MyObject> getByCompoundKey(Integer id2, Integer id2) {
  Map parms = new HashMap();
  parms.put("id1", id1);
  parms.put("id2", id2);
  return sqlSession.selectList("foo.Bar.getById", parms);
}

YMMV.

Jeff Butler



On Wed, Feb 17, 2010 at 2:36 PM, Rick R <ri...@gmail.com> wrote:
> On Wed, Feb 17, 2010 at 2:51 PM, Jeff Butler <je...@gmail.com> wrote:
>>
>> Using a mapper interface means you have a bit less code to write
>
> How is it less code?, that's my whole point in dropping it since I think it
> adds more code (for in our case seemingly little gain.) All my sql is in xml
> and for every mapper xml statement I create I have to go over and add a
> Mapper interface method. It's just one more piece of code that needs
> attention.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org

Re: If all my sql is in xml, do I gain that much (assuming unit tests) using Mapper objects as well?

[Rick R <ri...@gmail.com>]

On Wed, Feb 17, 2010 at 2:51 PM, Jeff Butler <je...@gmail.com> wrote:

> Using a mapper interface means you have a bit less code to write
>

How is it less code?, that's my whole point in dropping it since I think it
adds more code (for in our case seemingly little gain.) All my sql is in xml
and for every mapper xml statement I create I have to go over and add a
Mapper interface method. It's just one more piece of code that needs
attention.

Re: If all my sql is in xml, do I gain that much (assuming unit tests) using Mapper objects as well?

[Jeff Butler <je...@gmail.com>]

Using a mapper interface means you have a bit less code to write and
generics support comes for free without having to do the
@SuppressWarnings annotation.  Refactoring support is limited because
the mapper interface name and method names must match the XML - so
simply changing something in the mapper interface might break the
code.

The mapper is doing the same thing under the covers as what you
describe - so there's no other magic.  In my current project I'm using
the mapper interface because I like to write less code, and Ibator
generated most of the mapper methods anyway.

Jeff Butler


On Wed, Feb 17, 2010 at 1:38 PM, Rick R <ri...@gmail.com> wrote:
> This probably has been brought up before, but a quick search on nabble
> didn't return anything that useful at the moment...
>
> Our plan is to have ALL sql in the mapper xml files (not annotations.) It
> 'seems' like the only real benefit we'd then get out of also providing a
> corresponding mapper object is for IDE support and catching of any invalid
> calls early on (and maybe refactoring is slightly cleaner but that's
> debatable.)  But assuming we have a unit test for every mapper sql command
> in our service layer, is there anything else I miss by skipping the whole
> creation of mapper objects and simply going after the sql the old way...
> session.update("fooBar.updateEmployee", obj) ? (I read pages 53/54 of the
> guide and nothing jumped out at me as a huge gain in our case using Mapper
> classes.)
>
> I just don't want to be overlooking anything.
>
> --
> Rick R
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org