ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sundar Sankar" <fatboys...@gmail.com>
Subject Re: iBATIS DAO vs SqlMapClientDaoSupport
Date Mon, 12 Jan 2009 19:44:34 GMT
Rick,
You dont have to force yourself to using Spring at all. I have used Spring
and I know it makes your job easier. I would assume, using spring shouldnt
change your architechture too much. You might need to port in a few extra
jars but you get a lot of added advantage with it. I just dont see why the
customers would need to know spring at all.

In the first place, most of the "Spring code" would be in your Service
layer, which I assume, you would expose as an interface. This is no
different than any other interface that you might wanna expose. Plus using
spring 2.5 annotaions could make you use almost  "No xmls" too.

The way I see it, Instead of packaging the daos and ibatis jars, You would
package the daos, and service and other jars together and make it reusable.
In one of my earlier projects, I had a central bootstrap, that was spring
based and that would be the one on deciding on what to call and how to call
which is where I used spring and still made my persistence layer, reusable.
Spring does give you various ways of implementation. But to use it or not,
is, very project specific and I guess you gotto make that call yourself.

I have limited knowledge on your project and am sorry if I didnt answer your
problem straight.

-Sundar



On Mon, Jan 12, 2009 at 9: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?
>
> 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.
> >> >
> >
>
>
>
> --
> Rick
>

Mime
View raw message