Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 31954 invoked from network); 28 Oct 2006 20:32:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Oct 2006 20:32:01 -0000 Received: (qmail 70079 invoked by uid 500); 28 Oct 2006 20:32:12 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 69643 invoked by uid 500); 28 Oct 2006 20:32:10 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 69632 invoked by uid 99); 28 Oct 2006 20:32:10 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Oct 2006 13:32:10 -0700 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of jeffgbutler@gmail.com designates 64.233.182.185 as permitted sender) Received: from [64.233.182.185] (HELO nf-out-0910.google.com) (64.233.182.185) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Oct 2006 13:31:58 -0700 Received: by nf-out-0910.google.com with SMTP id l23so1719989nfc for ; Sat, 28 Oct 2006 13:31:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=lkqe78mNSM6WhPho88RJEuA9AjwXo8tMBJ4KL5iCvzmzuywySlUTZeGyWHqZNpeTG6hyI6ticDK+zYQMuKOzOs+9MED7W+efx7v/sbwbMhuYEfCI1xCh2rZExTo/Jv7a2RM4/aTzFfFvvWHl2NkyptKwwzQGkrd60kvWX09AtrM= Received: by 10.78.201.8 with SMTP id y8mr2014537huf; Sat, 28 Oct 2006 13:31:36 -0700 (PDT) Received: by 10.78.153.17 with HTTP; Sat, 28 Oct 2006 13:31:36 -0700 (PDT) Message-ID: Date: Sat, 28 Oct 2006 15:31:36 -0500 From: "Jeff Butler" To: user-java@ibatis.apache.org Subject: Re: Deprecating the DAO framework? In-Reply-To: <7f931f750610281319i6dd0f0a2uad8585acf89a3248@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_48553_27058647.1162067496477" References: <16178eb10610212328o3aac17fes1a6a12b946b39a93@mail.gmail.com> <7f931f750610281319i6dd0f0a2uad8585acf89a3248@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_48553_27058647.1162067496477 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The thinking goes like this... You don't have to use the DAO framework or Spring - many projects don't use either. You can write a perfectly acceptable application just using SQL maps. Most of my iBATIS work has been done this way. DOA doesn't really add anything in terms of transactions - in fact, it causes a lot of confusion in this area IMHO. You can do everything you want to do transactionally with the base SQL map functions. If you want to use the DAO framework, then you are probably starting to think about dependency injection (IoC) - and there are much better tools for this now. For example, Pico container supports all the IoC functions of the DAO framework and more. And it is very simple to use - I think they have a 5 minute introduction on their site. Jeff Butler On 10/28/06, Javier Urbaneja wrote: > > 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. > > Greetings. > > On 10/23/06, Jeff Butler 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 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 > > > > > > > > > ------=_Part_48553_27058647.1162067496477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
The thinking goes like this...
 
You don't have to use the DAO framework or Spring - many projects don't use either.  You can write a perfectly acceptable application just using SQL maps.  Most of my iBATIS work has been done this way.
 
DOA doesn't really add anything in terms of transactions - in fact, it causes a lot of confusion in this area IMHO.  You can do everything you want to do transactionally with the base SQL map functions.
 
If you want to use the DAO framework, then you are probably starting to think about dependency injection (IoC) - and there are much better tools for this now.  For example, Pico container supports all the IoC functions of the DAO framework and more.  And it is very simple to use - I think they have a 5 minute introduction on their site.
 
Jeff Butler


 
On 10/28/06, Javier Urbaneja <urbanejarl@gmail.com> wrote:
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.

Greetings.

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




------=_Part_48553_27058647.1162067496477--