I'll play with it and see how it looks.
I'm wondering if this new API should filter down to the SqlSession API as
well.. that is, introduce the RowLimit class to replace the offset and limit
integer parameters It kind of makes sense.
I bet people will be ticked that we're changing an interfa
> @Select("select * from employee where first_name = #{firstName} and
> last_name = #{lastName})
> List findEmployeesLike(@Param("firstName") String firstName,
> @Param("lastName") String lastName, Constraint offsetLimit);
Clinton, after considering all of your insightful remarks altogether
I've c
I don't think it's an opinion limited to myself and iBATIS... Gavin King and
Christian Bauer of Hibernate fame have also spoken out against them in the
past. I think a lot of people are coming to the conclusion that MVC +
Service + Persistence is enough layers. :-)
I couldn't find Gavin's origina
> DAOs have become the boilerplate in my opinion.
>
> ActionBean(Stripes) > Service(POJO) > Mapper(iBATIS)
Interesting. I dare to say that your point of view is clearly influenced by your
use of ibatis, isn't it? I can hardly imagine programming a services tier with
verbose jdbc or obscure hql emb
>From a matter of personal opinion, I no longer use DAOs... I wrote them for
years, and to no benefit. I've never swapped out a DAO implementation or
replaced the persistence framework, or at least not to the degree that the
mappers wouldn't allow for the same benefit.
DAOs have become the boiler
> 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
Ok, I was thinking in dao terms and my perception was "mappers are
almost daos... only if I had one more degree of freedom to define my
inte
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 fram
> thoughts on the following two options:
>
> @Select("select * from employee where first_name = #{firstName} and
> last_name = #{lastName})
> List findEmployeesLike(@Param("firstName") String firstName,
> @Param("lastName") String lastName, @Offset int offset, @Limit, int limit);
>
> @Select("sel
I think your point about the "prioritizing" the rest of the application
code, even at the expense of a bit of duplication in the interface, is a
good one. And if that's the case, I think my preference would be for this
syntax:
@Select("select * from employee where first_name = #{firstName} and
la
> I really wish Java made this easier. One thought I had to submit to the JCP
> was to add introspection on parameter names by having the compiler
> automatically create annotations for the parameter names.
This was scheduled for java 6 but it was postponed, now it seems unlikely
that java 7 will
Hi Clinton,
thanks for your detailed answer.
I agree with you, although leaving aside the SQLUtils varargs proposal,
I tend to priorize the unconstrained java mapper interface issue over
the parameter naming issue, because
(i) the interface defines a contract for the rest of the application
I love the idea, and I think we even have it on the wiki...
However, I attempted the implementation and could not land on a design that
was nice. The biggest problem is that Java lacks introspection on method
parameter names. What I would really love is:
@Select("select * from employee where fi
> It just requires a trivial modification in MapperMethod and a simple
> mechanism to access positional parameters to get it working. For
> example, MapperMethod could create a Map and put the first argument
> under the key "first", the second one under "second", etc. That is,
> positional access "
Hi all,
now that ibatis 3 supports type-safe mapper interfaces that make a
nice interface to the repository/dao tier, it would be desirable to
allow for multiple parameters to be passed, so that application
designers would not be constrained while designing their layer
interfaces. For example, I w
14 matches
Mail list logo
