1. I think all of you are missing one big feature of iBatis: the Dao framework.
Even though, you like Hibernate, JDBC, SQL maps or any other kind/package for persistence, in my opinion iBatis is always present (maybe not for EJBs... but I cant talk of what I havent studied). The Dao framework plays a fantastic role for abstracting the way I implement persistence and for giving me the possibility of making another option in the future. 2. About Hibernate itself, one of the things I donšt like is the HQL... If I have to use HQL, then I would prefer plain old SQL... or use a possible industry standard (JDO/JDOQL). You should take a look at OJB and Torque because, even though, they seem to be less popular, they are also very good options. You can use Hibernate's documentation to learn the basics of OR mapping (the documentation is, in fact, pretty good) and then try using another framework. I have been using OJB for quiet a while and I am delighted with the results. More, you can write you own persistence API and implement it so you can switch easily between frameworks (the iBatis Dao framework with all of the templates opens some possibilities for this, by implementing the Templates). Regards, Pedro Salgado On 1/9/04 10:04 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > >> I didn't see that you could use straight sql in Hibernate > You can - that's why we went with it. We can let it do it's stuff, but if > we need to we can override it with sql > > > > |---------+----------------------------> > | | "Nail, Evan | > | | Burke" | > | | <[EMAIL PROTECTED]| > | | com> | > | | | > | | 09/01/2004 04:55 | > | | PM | > | | Please respond to| > | | "Struts Users | > | | Mailing List" | > | | | > |---------+----------------------------> >> ----------------------------------------------------------------------------- >> -------------------------------------------| > | > | > | To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > | > | cc: > | > | Subject: RE: Hibernate VS ibatis, which is better? > | >> ----------------------------------------------------------------------------- >> -------------------------------------------| > > > > > I've just looked at Hibernate a little so I am no expert, but it was pretty > powerful. But we really didn't need most of what it did, so we went with > iBatis. Although I doubt I am pronouncing it right even now. > > We just wanted something to map beans to sql and didn't want to worry about > a new QL ( I didn't see that you could use straight sql in Hibernate and > alas I hate QL). We didn't need to generate beans from tables or tables > from beans or anything like that. We tried a few and the beans never got > generated exactly correct, but that might be configurable. > > Hibernate seemed more powerful but also more complicated. > > Ibatis takes about 15 minutes to figure out and get up and running. It's > persistent managers take a little while to set up, but it just seemed > quicker off the line. Our db was already there, so if you were a new > project and changing schemas often, Hibernates ability to gen beans from > tables etc might be nice. > > I have not done any type of performance testing. > > bn > > > > > > > -----Original Message----- > From: struts Dude [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 01, 2004 3:37 PM > To: Struts Users Mailing List > Subject: Hibernate VS ibatis, which is better? > > > Hello > > Just want some feedback from ppl who know > both. Which one is more powerful and easier > to use? > > Personally I only know iBatis but seeing so > many web app built on hibernate and even > a book on hibernate to be published, just > wandering if it's worth my time to learn hibernate. > > Thanks > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > ********************************************************************** > This e-mail is the property of Enron Corp. and/or its relevant affiliate > and may contain confidential and privileged material for the sole use of > the intended recipient (s). Any review, use, distribution or disclosure by > others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the sender or > reply to Enron Corp. at [EMAIL PROTECTED] and delete > all copies of the message. This e-mail (and any attachments hereto) are not > intended to be an offer (or an acceptance) and do not create or evidence a > binding and enforceable contract between Enron Corp. (or any of its > affiliates) and the intended recipient or any other party, and may not be > relied on by anyone as the basis of a contract by estoppel or otherwise. > Thank you. > ********************************************************************** > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
