ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: iBATIS DAO vs SqlMapClientDaoSupport
Date Fri, 09 Jan 2009 19:47:23 GMT
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 <rickcr@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 2:25 PM, Jeff Butler <jeffgbutler@gmail.com> 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.

View raw message