You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Rick <ri...@gmail.com> on 2009/01/09 17:34:08 UTC
iBATIS DAO vs SqlMapClientDaoSupport
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.
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
On Fri, Jan 9, 2009 at 7:08 PM, Nathan Maves <na...@gmail.com> wrote:
> I use guice to inject a SqlMapClient object into my dao implementations.
> then I just call the methods on that object as needed.
I'd like to see an example of this.
How are using your these DAOs from other classes? I'm really curious about this.
One of the limitations of using IoC, at least with Spring, is that you
seem to be stuck with the whole ball of wax on the implementation end
unless you want to provide ugly hooks in your enpoints that do
something like applicationContext.getBean("something",
Something.class).
for example if you have:
SomeClass {
FooBar foobar; //IOC injected!
method() {
foobar.something();
}
you can't just use someClass.method unless where you are calling it
from is under your IoC framework as well of which SomeClass is defined
somewhere (in spring under a config file.) So I'm curious how you are
saying guice can handle this, if it even can.
--
Rick
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Nathan Maves <na...@gmail.com>.
I use guice to inject a SqlMapClient object into my dao implementations.
then I just call the methods on that object as needed.
On Fri, Jan 9, 2009 at 1:03 PM, Rick <ri...@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 2:47 PM, Jeff Butler <je...@gmail.com> wrote:
> > 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.
>
> Sounds good. I think I'll just roll my own since I really don't need
> the IoC stuff. Thanks Jeff.
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Clinton Begin <cl...@gmail.com>.
Feel free to grab the iBATIS DAO source and make it your own.
No need to start from scratch... it's Apache licensed... :-)
Clinton
On Fri, Jan 9, 2009 at 1:03 PM, Rick <ri...@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 2:47 PM, Jeff Butler <je...@gmail.com> wrote:
> > 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.
>
> Sounds good. I think I'll just roll my own since I really don't need
> the IoC stuff. Thanks Jeff.
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
On Fri, Jan 9, 2009 at 2:47 PM, Jeff Butler <je...@gmail.com> wrote:
> 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.
Sounds good. I think I'll just roll my own since I really don't need
the IoC stuff. Thanks Jeff.
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Jeff Butler <je...@gmail.com>.
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 <ri...@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 2:25 PM, Jeff Butler <je...@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.
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
On Fri, Jan 9, 2009 at 2:25 PM, Jeff Butler <je...@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.
Re: unsubscribe
Posted by Larry Meadors <la...@gmail.com>.
http://ibatis.apache.org/mailinglists.html
unsubscribe
Posted by "Rajaram, Naresh" <Na...@fairisaac.com>.
This email and any files transmitted with it are confidential, proprietary
and intended solely for the individual or entity to whom they are addressed.
If you have received this email in error please delete it immediately.
unsubscribe
Posted by "Ou, Stan (Mission Systems)" <ST...@ngc.com>.
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Sundar Sankar <fa...@gmail.com>.
The effort should also include handling batch cruds !
On Mon, Jan 12, 2009 at 4:11 PM, Sundar Sankar <fa...@gmail.com> wrote:
> Can I put it across this way,
>
> You would wanna perform Crud using Ibatis, what would be your design to use
> Ibatis. If you could define what tasks(patterns or code) you might need to
> do for all the work of an enterprise, thats a start.
> Please state, class for maintaining connection pool, (Am assuming since it
> is just ibatis, u aint using a connection pool framework too) transaction
> single and multiple, exception handling, logging, managing states of your
> object blah blah blah. In short you data access framework.
>
> My Guess is, All of the above is already available in Spring.
>
> -Sundar
>
>
> On Mon, Jan 12, 2009 at 3:58 PM, Rick <ri...@gmail.com> wrote:
>
>> On Mon, Jan 12, 2009 at 4:50 PM, Sundar Sankar <fa...@gmail.com>
>> wrote:
>> > By reinventing I was talking of , connection pool / management,
>> transaction
>> > management etc etc.
>>
>> Transaction demarcation in Spring is sort of nice. I will give it a
>> "plus" for that (Although I like it even better in EJB3.)
>>
>
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Sundar Sankar <fa...@gmail.com>.
Can I put it across this way,
You would wanna perform Crud using Ibatis, what would be your design to use
Ibatis. If you could define what tasks(patterns or code) you might need to
do for all the work of an enterprise, thats a start.
Please state, class for maintaining connection pool, (Am assuming since it
is just ibatis, u aint using a connection pool framework too) transaction
single and multiple, exception handling, logging, managing states of your
object blah blah blah. In short you data access framework.
My Guess is, All of the above is already available in Spring.
-Sundar
On Mon, Jan 12, 2009 at 3:58 PM, Rick <ri...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 4:50 PM, Sundar Sankar <fa...@gmail.com>
> wrote:
> > By reinventing I was talking of , connection pool / management,
> transaction
> > management etc etc.
>
> Transaction demarcation in Spring is sort of nice. I will give it a
> "plus" for that (Although I like it even better in EJB3.)
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
On Mon, Jan 12, 2009 at 4:50 PM, Sundar Sankar <fa...@gmail.com> wrote:
> By reinventing I was talking of , connection pool / management, transaction
> management etc etc.
Transaction demarcation in Spring is sort of nice. I will give it a
"plus" for that (Although I like it even better in EJB3.)
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Sundar Sankar <fa...@gmail.com>.
By reinventing I was talking of , connection pool / management, transaction
management etc etc. I agree, you could do without spring and you could do
without Ibatis too, You do without Struts and just use servlets. You could!
But do u ? In an overall persona, Spring gives u great leverage. Ibatis to
Spring is probably not the right parameter to judge Spring. I am not Spring
crazy too. But I def feel It is better way to code and it does save a lot of
time.
I am guessing you havent implemented Spring in a full fledge project. I was
assuming it aint gonna work and it would be a waste of time too before my
first Spring project. But just when the project was half way, i did realise
its benefits. It is a good tool and am reiterating again, to see if it is
the right tool for you currently and going forward in your project, you
should be the one to decide.
I am sorry to say, I dont feel this is the right forum to talk about Spring
any more and I feel there would be better answers if you posted the same on
the Spring forum too.
Good luck with your project!
-Sundar
On Mon, Jan 12, 2009 at 2:21 PM, Rick <ri...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 4:08 PM, Sundar Sankar <fa...@gmail.com>
> wrote:
> > Yes. Our project did take configurable prop files. But it didnt do just
> > that. But looks like your need is to take a prop file and return an
> object
> > after hitting the db the prop file points to. Spring wouldnt be
> neccessary
> > if thats your used case.
> >
> > But I personally wouldnt wanna reinvent the wheel and waste time and
> money
> > on writing code and more so on testing the same for something that is
> > already available and well tested.
>
> iBATIS gets the properties file for you. There is no "reinventing." :
>
> <sqlMapConfig>
> <properties resource="database.properties"/>
>
> I'm not trying to be a jerk, but I am curious what you are truly
> gaining using Spring. I'm not anti-spring but use it where it gives
> you an advantage. What true advantage are you gaining using it? (I do
> see some places where Spring really helps (hard-core test driven
> development) but I'd be willing to bet 90% or more are using Spring
> without TDD in mind and they would have saved time not even using
> Spring in the first place.)
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
On Mon, Jan 12, 2009 at 5:42 PM, Sundar Sankar <fa...@gmail.com> wrote:
> I guess I missed this one. But why do u need to use
> applicationContext.getBean. Those are ancient man. With Spring Annotations
> (check the 2.5+ documentation), U hardly need xmls and all of this crappy
> code.
Yes you did miss it. Annotations aren't going to help you have an
external client (that is not under Spring control) use your jar to get
access to a classes that have objects injected via Spring. You need a
different approach.
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Sundar Sankar <fa...@gmail.com>.
I guess I missed this one. But why do u need to use
applicationContext.getBean. Those are ancient man. With Spring Annotations
(check the 2.5+ documentation), U hardly need xmls and all of this crappy
code.
I am not sure if that and the need for those huge amounts of xmls worried u
about Spring as such. But Those were my $0.02 about the same.
-S
On Mon, Jan 12, 2009 at 2:54 PM, Chris O'Connell <
oconnell@gorillachicago.com> wrote:
> I have used Spring to configure multiple instances of the same set of DAO's
> to hit different databases. Right there Spring has a huge advantage over
> having to hardcode a specific config file right into the code. Also, using
> DI makes it easier to code against interfaces and let Spring worry about
> having to instantiate the correct instance of that interface. You haven't
> indicated anything about who is actually going to be creating all the
> objects you will be needing. I'm a big fan of the rule that code should
> either use an object or create it, but not both. That doesn't necessarily
> have anything to do with iBatis, but Spring's DI certainly makes that
> easier.
>
> Once again, if Spring doesn't solve any of your problems, don't use it.
> But your reasons for not using it seem a little inconsistent. You state
> that the only thing that Spring would do for you is allow you to use a
> Spring utility class. But you then state that you don't want to use DI
> because you don't want clients of your API to depend on Spring. Well, those
> things really are independent of each other. I have nothing to gain by you
> using Spring, but you might want to take another look at what Spring really
> does before you decide you don't want to use it.
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
On Mon, Jan 12, 2009 at 4:54 PM, Chris O'Connell
<oc...@gorillachicago.com> wrote:
> I have used Spring to configure multiple instances of the same set of DAO's
> to hit different databases. Right there Spring has a huge advantage over
> having to hardcode a specific config file right into the code.
Why is that such an advantage? Why is hard-coding a config file so bad
that? Seriously, most people are all annotation crazy now anyway and
have gone away from wanting configuration in xml files. So my
configuration file in my Java code.
> Also, using DI makes it easier to code against interfaces and let Spring worry about
> having to instantiate the correct instance of that interface.
Please give me the specific case where you are swapping out
implementations of your interface pre-run-time? Again, I'm not saying
this to be confrontational.. I HAVE used spring in some end-to-end
J2EE projects. It makes the most sense when you want different
concrete implementations used for testing, but how many of you are
using it for that purpose? You're actually making a bunch of mockDAOs?
> You haven't
> indicated anything about who is actually going to be creating all the
> objects you will be needing.
I did another post. It's simple. I just make my DAO a singleton. Sure
it's about 5 lines that Eclipse can generate for me. Yes, I understand
Spring will inject them as Singletons by default. 5 lines of
auto-generated Java code isn't a show stopper.
> I'm a big fan of the rule that code should
> either use an object or create it, but not both. That doesn't necessarily
> have anything to do with iBatis, but Spring's DI certainly makes that
> easier.
So you use Spring to give you an instance of a StringBuilder also?
> Once again, if Spring doesn't solve any of your problems, don't use it.
> But your reasons for not using it seem a little inconsistent. You state that
> the only thing that Spring would do for you is allow you to use a Spring
> utility class. But you then state that you don't want to use DI because you
> don't want clients of your API to depend on Spring. Well, those things
> really are independent of each other.
Well from what I understand the utility class does rely on using DI so
not sure how they are that independent, but I might be missing what
your getting at.
> I have nothing to gain by you using
> Spring, but you might want to take another look at what Spring really does
> before you decide you don't want to use it.
Again, I have used Spring. I understand what dependency injection is.
(I understand it can also do some AOP stuff also), but right now I'm
not seeing the huge advantage of adding an extra layer of complexity
to the application just to avoid me creating singletons or new
instances of objects. I'm not saying Spring is difficult either
(although it is a bit when it comes to Tomcat and getting JPA stuff
working correctly.))
What I'd really like are the concrete ways using Spring has helped
some of you in regard to your "ibatis persistence" (I'm not referring
to othe areas, remember all I need is a peristence jar). You first
mentioned having DAO use a different DB. In my case I just change the
config file that is loaded in the base DAO. easy.
You then mentioned the philosophical thing about not wanting to be
responsible for both tasks: creating objects and using them. Ok fine,
if you are using that for an argument how Spring is helpful, I can't
argue with it, since its purely philosophical and don't see a
practical benefit, since the 'creation' is just pushed off somewhere
else.
Interesting conversation though. (I hope my tone isn't sounding
confrontational. I'm just too lazy to type a lot:)
--
Rick
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Chris O'Connell <oc...@gorillachicago.com>.
I have used Spring to configure multiple instances of the same set of DAO's
to hit different databases. Right there Spring has a huge advantage over
having to hardcode a specific config file right into the code. Also, using
DI makes it easier to code against interfaces and let Spring worry about
having to instantiate the correct instance of that interface. You haven't
indicated anything about who is actually going to be creating all the
objects you will be needing. I'm a big fan of the rule that code should
either use an object or create it, but not both. That doesn't necessarily
have anything to do with iBatis, but Spring's DI certainly makes that
easier.
Once again, if Spring doesn't solve any of your problems, don't use it. But
your reasons for not using it seem a little inconsistent. You state that
the only thing that Spring would do for you is allow you to use a Spring
utility class. But you then state that you don't want to use DI because you
don't want clients of your API to depend on Spring. Well, those things
really are independent of each other. I have nothing to gain by you using
Spring, but you might want to take another look at what Spring really does
before you decide you don't want to use it.
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
On Mon, Jan 12, 2009 at 4:08 PM, Sundar Sankar <fa...@gmail.com> wrote:
> Yes. Our project did take configurable prop files. But it didnt do just
> that. But looks like your need is to take a prop file and return an object
> after hitting the db the prop file points to. Spring wouldnt be neccessary
> if thats your used case.
>
> But I personally wouldnt wanna reinvent the wheel and waste time and money
> on writing code and more so on testing the same for something that is
> already available and well tested.
iBATIS gets the properties file for you. There is no "reinventing." :
<sqlMapConfig>
<properties resource="database.properties"/>
I'm not trying to be a jerk, but I am curious what you are truly
gaining using Spring. I'm not anti-spring but use it where it gives
you an advantage. What true advantage are you gaining using it? (I do
see some places where Spring really helps (hard-core test driven
development) but I'd be willing to bet 90% or more are using Spring
without TDD in mind and they would have saved time not even using
Spring in the first place.)
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Sundar Sankar <fa...@gmail.com>.
Yes. Our project did take configurable prop files. But it didnt do just
that. But looks like your need is to take a prop file and return an object
after hitting the db the prop file points to. Spring wouldnt be neccessary
if thats your used case.
But I personally wouldnt wanna reinvent the wheel and waste time and money
on writing code and more so on testing the same for something that is
already available and well tested.
-Sundar
On Mon, Jan 12, 2009 at 1:23 PM, Rick <ri...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 2:44 PM, Sundar Sankar <fa...@gmail.com>
> wrote:
> >
> > 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.
>
> And what if your end client didn't wanted to create a central
> bootstrap that was spring based? How well would your daos work in your
> packsge then?
>
> In my case I can say "Hey use this jar. Just provide your
> database.properties file in your classpath." Done.
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
On Mon, Jan 12, 2009 at 2:44 PM, Sundar Sankar <fa...@gmail.com> wrote:
>
> 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.
And what if your end client didn't wanted to create a central
bootstrap that was spring based? How well would your daos work in your
packsge then?
In my case I can say "Hey use this jar. Just provide your
database.properties file in your classpath." Done.
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Sundar Sankar <fa...@gmail.com>.
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 <ri...@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
> <Ge...@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 <ri...@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
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
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...
UserDao.getInstance().getUser(id);
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 =
DaoUtil.loadSqlMapClient("sqlMapConfig-gui.xml");
}
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
<oc...@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 <ri...@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?
>>
>
>
--
Rick
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Chris O'Connell <oc...@gorillachicago.com>.
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 <ri...@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?
>
>
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Rick <ri...@gmail.com>.
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
<Ge...@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 <ri...@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
RE: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Gerbrand van Dieijen <Ge...@whitehorses.nl>.
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 <ri...@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.
> >
Re: iBATIS DAO vs SqlMapClientDaoSupport
Posted by Jeff Butler <je...@gmail.com>.
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 <ri...@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.
>