ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris O'Connell" <oconn...@gorillachicago.com>
Subject Re: iBATIS DAO vs SqlMapClientDaoSupport
Date Mon, 12 Jan 2009 19:10:51 GMT
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?
>
>

Mime
View raw message