> 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
