> thoughts on the following two options:
>
> @Select("select * from employee where first_name = #{firstName} and
> last_name = #{lastName})
> List<Employee> findEmployeesLike(@Param("firstName") String firstName,
> @Param("lastName") String lastName, @Offset int offset, @Limit, int limit);
>
> @Select("select * from employee where first_name = #{firstName} and
> last_name = #{lastName})
> List<Employee> findEmployeesLike(@Param("firstName") String firstName,
> @Param("lastName") String lastName, Constraint offsetLimit);
>
Prima facie I would prefer the first option, because the current implementation,
(ie. with no parameter annotations) could be considered the default case. It
makes a very good default indeed. Most of the methods that return or update
one entity will match the one parameter signature, and those queries that
return collections will match the one or three parameters signature,
the last two ones for the offset/limit constraint. Following Pareto,
no annotations or special classes should be required for these common cases.
Also, I don't like the idea of introducing an IBatis specific class at the dao
layer (which is supposed to isolate the application from the specific
persistence technology employed, at least to a reasonable degree),
but then you're right that we already have ResultHandler anyway.
Besides the annotations question, I think the above is pointing out a
deeper issue. As far as IBatis is being all that smart creating the
entire mapper on the fly from an interface, it leaves no fine tunning
options to the application designer/programmer, except by means of
an in-place metadata mechanism that soon becomes awkward, limited and
verbose (we are pushing it to the limit here, in fact). That was my point before
about being relieved of the old boilerplate, but then: maybe excessively
relieved.
Why is it that you're using java dynamic proxies here instead of cglib
or javassist proxies? To avoid external dependencies at all costs?
Would you provide a cglib variant if enhance is enabled? This way one
could think (just brainstorming) of a combination of automagically
generated methods and other hand written ones that allow for complete
customisation of the 20% cases that don't follow the rule, by delegating
to internal protected autogenerated methods or just by directly calling
the SqlSession as in the old times. It would be a "best of both worlds"
approach. A combination of abstract and concrete methods will do the trick,
interfaces being the "degenerate" case for which all methods are abstract.
This could even solve the multiple parameter naming issue: you want it,
write it, IBatis won't do it for you but won't forbid you to do it either.
Also, if you don't care about exposing IBatis specific interfaces to the
rest of the application, go ahead with ResultHandler, for example. But
if you DO care, write your own MyAppResultHandler and your dao method
that accepts it (again, as a "full-fledged" implementation on top of
SqlSession or as an adaptor stub to an autogenerated method).
Best regards
--
Carlos
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
