These mapper classes aren't meant to be DAOs... they're meant to be mappers.
If you like a DAO pattern, then you can still use it, with or without mapper
classes. The mapper class's only goal is to eliminate the string literals
and casting that comes with the "old way".
We deprecated the DAO framework and don't intend to replace it, as there are
better alternatives like Guice and Spring.
iBATIS does optionally use CGLIB for certain things (lazy loading on
concrete types), but it's not a requirement. If it's on the classpath,
iBATIS will use it, if it's not, iBATIS won't. For the case of the mappers,
it's simply not needed.
I see what you're saying about the concrete methods, but I don't think I'd
take iBATIS in that direction.
However, it's perfectly possible to build such a thing external to iBATIS...
the mapper framework in iBATIS is very small and simple. If you're
interested in that approach, perhaps you could put something together for
yourself, and then post the implementation here. The community can look at
it. It might become a popular extension, or maybe a core addition. In the
worst case scenario, you'd get to use it. :-)
Clinton
On Sun, Aug 30, 2009 at 2:16 PM, <carlosjosep...@gmail.com> wrote:
> > 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
>
>
