ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: Unconstrained signature interface mappers for ibatis 3
Date Mon, 31 Aug 2009 02:28:21 GMT
>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 boilerplate in my opinion.  It think it's more
important to have a good services layer - with or without interfaces - that
defines your business logic.  So my current favourite layer structure would
be something like:

ActionBean(Stripes) > Service(POJO) > Mapper(iBATIS)

With all dependencies injected/managed by Guice.

>> so I would need to patch the code.

I don't think you'd have to patch the code... You can implement your own
SqlSessionFactory and SqlSession instances, decorated with your
implementations.  That's done by design for this reason.  You can also wrap
or extend the Configuration class.

Don't try to augment the existing mapper implementation, just replace it
entirely with yours.

Cheers,
Clinton


On Sun, Aug 30, 2009 at 8:06 PM, <carlosjosepita@gmail.com> wrote:

> > 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
> interfaces... ". In fact, I'm porting an entire application persistence
> tier to ibatis, and the correspondence between mappers and daos is
> almost complete except for the minor differences between signatures. Now I
> will need some refactoring at the use-point (application/services tier)
> or, alternatively, to implement thin adaptors daos that delegate to
> mappers,
> preserving the original interfaces. That's a lot of boilerplate, or another
> level of bytecode manipulation wizardry. That was my motivation and
> rationale,
> but it's fine if it's out of the intended scope for mappers.
>
> > 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
>
> Sure. One simple way would be to implement a cglib enhanced variant
> of the current MapperProxy, but there is no extension point from where
> to instantiate different proxy implementations, so I would need to patch
> the code. Anyway, I guess you're suggesting something on top of mappers
> and not in place of mappers, according to your comments above. I'll
> think about it.
>
> Thank you!
>
> Best regards
> --
> Carlos
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>

Mime
View raw message