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 16:55:11 GMT
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?

On Mon, Jan 12, 2009 at 4:31 AM, Gerbrand van Dieijen
<Gerbrand.van.Dieijen@whitehorses.nl> wrote:
> Hello,
> I'm a new IBatis-user and member to this list. I don't know a lot about
> IBatis yet, but I do want to comment on Spring. I use Spring a lot.
> Although Spring gets more and more modules, it's still not bloated. The
> Dependency-Injection (DI) framework is still as simple as it was before
> to use, you add and use extra spring-modules only if you need to.
> Setting up any DI framework may be some work at first, but very soon
> it'll save from creating lot of boiler-plate code and
> re-inventing-the-wheel.
> Retrieving the application context in spring is very easy. Assuming you
> use servlets, you'll have to do add the following to the web.xml:
>        <!--
>                Spring config contextKey
>    -->
>        <context-param>
>                <param-name>contextConfigLocation</param-name>
>                <param-value> /WEB-INF/config/spring-service-config.xml
> </param-value>
>        </context-param>
>        <!-- Spring Listener -->
>        <listener>
>                <listener-class>
> org.springframework.web.context.ContextLoaderListener </listener-class>
>        </listener>
>        <listener>
>                <listener-class>
> org.springframework.web.context.request.RequestContextListener
> </listener-class>
>        </listener>
> After that retrieving the application context, and retrieving a bean can
> done as follows:
> ApplicationContext context =
> WebApplicationContextUtils.getWebApplicationContext(getServletContext())
> ;
> Object myDao = context.getBean("daoBeanName");
> Regards,
> Gerbrand van Dieijen
> Consultant
> Java/JEE/SOA
> Whitehorses B.V.
> E-mail: gerbrand.van.dieijen@whitehorses.nl
> Telefoon: +31 (0)30 600 4720
> Mobiel: +31 (0)6 52413702
>> -----Oorspronkelijk bericht-----
>> Van: Jeff Butler [mailto:jeffgbutler@gmail.com]
>> Verzonden: vrijdag 9 januari 2009 20:26
>> Aan: user-java@ibatis.apache.org
>> Onderwerp: Re: iBATIS DAO vs SqlMapClientDaoSupport
>> 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 <rickcr@gmail.com> 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.
>> >


View raw message