ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick <ric...@gmail.com>
Subject Re: iBATIS DAO vs SqlMapClientDaoSupport
Date Mon, 12 Jan 2009 20:20:36 GMT
The questions is what does using DI give me vs what it makes harder?

I was only using Spring so I can use the SqlMapClientDaoSupport?

Do you realize how easy this is to code without Spring? Do I really
want to use Spring just so I can extend SqlMapClientDaoSupport? I have
0 config and my end users' can just call...


On my end... all I need is a single UserDao that extends a BaseDao
where the baseDao looks like....

public abstract class GuiDAO  {
    public static SqlMapClient sqlMap =

Look how EASY it is.

Tell me honestly how much you are gaining by using Spring (purely in
regard to iBATIS, not the rest of the application.)

The only real benefit I see is if I wanted to pass mock DAOs into my
service class that weren't ibatis ones for testing. To be honest, I
really think that step is a waste of time. I make sure I have unit
tests for all my real DAOs and my Service classes using these DAOs.
Making some mockDAO first that doesn't do any real work just to test a
service call, is just effort that I don't find that useful, since I'm
just going to turn around use a real DAO right after.

Someone please tell me what big benefit you are gaining from Spring?
(Ok yea i guess it's 'sort of' neat if you want to define some
transaction boundaries in an xml file, but I've never once found that
to be an issue.)

I'm really serious, please explain to me how much Spring is helping
you for your ibatis layer?

I don't want SpinalTap answer "Well, this one goes to a 11." :)

On Mon, Jan 12, 2009 at 2:10 PM, Chris O'Connell
<oconnell@gorillachicago.com> wrote:
> Rick,
> I certainly understand your point (and I'm not trying to be combative), but
> I think you are asking the wrong question.  You can ask "Why should I
> require my end user to use Spring"?  But, I'll ask you back, why are you
> requiring them to use iBatis?  They just really want to get at data in a
> database.  You could come up with a solution that doesn't use iBatis, just
> like you could come up with a solution that doesn't use Spring.  If you have
> a simple way to solve your problem, then you should use that regardless of
> what the technology is.  For example, if you use Spring and want to expose
> classes to them, why not write a simple Service Locator (or ObjectFactory or
> whatever) that knows about Spring and can create objects for the end user
> (I'd argue that that is a good idea in any case, Spring or not).
> Sorry if I am beating a dead horse, but you said you decided against using
> dependency injection because you don't want to force your end user to use
> Spring.  I would say that that is the wrong reason to decide against using
> DI.  Decide against Spring because it doesn't fit your technology
> requirements.  Decide against DI because it doesn't solve your problem.
> In any case, good luck putting your project together.
> On Mon, Jan 12, 2009 at 10:55 AM, Rick <rickcr@gmail.com> wrote:
>> Gerbrand, I understand how to use Spring to load what I need in
>> ibatis, but I decided against using Spring (or any dependency
>> injection) and here is why:
>> Let's say you want you to make your ibatis persistence jar in
>> different applications - not just a web app. Since you are using
>> Spring, you are forcing the end user of your jar to use Spring as
>> well... OR you are going to have do some annoying hacks in all of your
>> class that you want to expose to your end user (such as getting the
>> spring context and manually looking up the dao you want to return.)
>> In my case my end product ibatis persistence jar is completely
>> standalone. All the end user of the jar needs to provide in their
>> classpath is a database.properties file and whamo it just works. Why
>> should I force my end user of the jar to HAVE to use Spring or Guice?


View raw message