iBATIS DAO is deprecated, so probably won't be enhanced, may not work with future version of iBATIS, etc. But it works perfectly well as a simple IoC type of container with a bent towards iBATIS.
Spring is cool but getting bloated. If you only need IoC there are simpler alternatives like guice (already mentioned) or even Pico Container. I've used Pico Container before and can vouch for it's simplicity and function. But it sounds like you might not even need a full IoC capability. What's wrong with writing a little plumbing code yourself and just being done with it? Jeff Butler On Fri, Jan 9, 2009 at 10:34 AM, Rick <[email protected]> wrote: > I'm curious about your thoughts on using the ibatis DAO over the > Spring stuff? I'm really only using Spring for being able to extend > SqlMapClientDaoSupport. I'm not doing anything super cool with > swapping out test dao's etc with a different implementation, so I'm > thinking using the preferred Spring approach could be overkill due to > what I want... > > One of the concerns I have is I want others to be able to use my > persistence jar in other projects. I think forcing them to use Spring, > at least for look ups, could be a bad idea. For example say I have a > dao or service that I want to use from another jar... I want to be > able to do something like: > > UserDAO.getInstance().getUser(id); > > instead of relying on that dao being injected into the implementer's > code via spring. Having spring do the injection of the sqlMapClients > in my persistence jar though will I think require that getInstance > method will complicate things since I'll have to get access to > Spring's ApplicationContext and probably make some objects > AppliactionContextAware etc. > > I don't mind giving up Spring in this case, but am I giving up a lot > not using the SpringDAO implementation? How do other's make their > persistence stuff reusable if they end up using Spring? - don't you > then up forcing the end user' to have to create a spring-context.xml > file? I'd like to avoid that. >
