ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Javier Urbaneja" <urbanej...@gmail.com>
Subject Re: Deprecating the DAO framework?
Date Sat, 28 Oct 2006 20:19:45 GMT
It's not that I don't agree with you about the existence of better options.
It's just that with iBATIS you can start working with a persistence layer,
including DAOs in a work day, with the nice docs of SqlMaps and the DAO
framework (less than 100 pages together).
If you are going to use Spring DAO with iBATIS, at least you have to open
the Spring project web and realize which part you want to use. I believe all
of you will agree with me, that process will take you more than one work
day, if you have no previous knowledge about Spring.
Maybe embedded databases HSQL and McKoi are not as active as some time ago,
but they should not close down the projects because of Derby. Well, that's
my opinion.


On 10/23/06, Jeff Butler <jeffgbutler@gmail.com> wrote:
> +1
> I also think Spring DAOs are a better option these days.  iBATIS DAO was
> cool before Spring, Pico, etc. but it is looking a little dated.  I see no
> reason to make it more functional when there are great alternatives.
> Jeff Butler
> On 10/22/06, Clinton Begin <clinton.begin@gmail.com> wrote:
> >
> > Hi all,
> >
> > I think we should deprecate the iBATIS DAO framework for these reasons:
> >
> >
> >    - In my opinion, the iBATIS Mapper does a fantastic job of
> >    isolating the persistence layer as is.
> >    - I've personally started to shy away from data access layers.
> >    - For most applications, there's no big deal in having a
> >    dependency on SqlMapClient.
> >    - If you do use a DAO layer, I suggest Spring DAO
> >    - If you can't use Spring DAO, I suggest writing your own DAO
> >    layer that is as simple as possible and tuned for your environment.
> >    - I don't believe very many people use the DAO framework, for
> >    those that do, you can safely continue to do so.  It hasn't changed in
> >    years, and so it likely won't.
> >
> > Deprecation would basically mean we take it off the website as a
> > downloadable component and remove the doc links etc.  Of course we'd still
> > answer the odd question on the mailing list, but we'd likely not adopt any
> > changes and possibly not even fix any bugs (but you're welcome to take the
> > source and use it under the Apache License).
> >
> > What do you think?  Thoughts?
> >
> > Cheers,
> > Clinton
> >
> >

View raw message