I meant that you could write plumbing code to support whatever you want your persistence interface to look like.
Spring SqlMapClientDaoSupport is IoC enabled, and also supports Spring's translation of SQLException into more meaningful runtime exceptions. If you don't need that, then I'd just roll your own. Jeff Butler On Fri, Jan 9, 2009 at 1:40 PM, Rick <[email protected]> wrote: > On Fri, Jan 9, 2009 at 2:25 PM, Jeff Butler <[email protected]> wrote: >> 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? > > Plumbing code to support what - using SqlMapClientDaoSupport? That's > all I was trying to avoid was having to write a base dao that does > queryForList, queryForObject etc. It's not a big deal though to just > write them myself, since in the past that's how i've always done it > before Spring, I just build a BaseDAO that handled those methods. > Sounds like I might just go back to that, because you are correct in > that I do NOT need IoC. All I want is a simple persistence jar that > has some service classes and daos that do their thing against a few > different databases that we have. >
