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