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 <ric...@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-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
