Slashdot Mirror

We were one of the earliest adopters of Hibernate. In fact, we even took the Hibernate source code and altered it to meet our needs. Eventually we encountered complex problems that couldn't be solved with Hibernate and settled for iBATIS instead. We have to write our own queries but that's a given for any complex project. And I personally like the idea of placing your queries in an XML resource file. Perhaps this is doable with Hibernate now but at the time it wasn't.

iBATIS looks at first glance like Teh suck. Where's the basic documentation?

ie, From the front page of http://www.ibatis.com/ click on the small "Wiki, FAQ, IRC" link. Near the bottom of that page, locate a tiny "FAQ" link and click it, and go to a page that tells you that "Frequently 20Asked 20Questions This page does not exist yet." And suggests I try "Frequently Asked Questions" instead. Click this, and at long last you get to the FAQ

- The FAQ does not answer the questions "What is iBATIS?", "What does iBATIS do?", "why/when would I want to use iBATIS?" or any closely related question. I get bored and wander off in search of a meaningful interaction.

iBATIS SqlMaps is my persistance *assistance* technology of choice, and have been for two years.

Thank you for the response.

but sooner or later you're going to do a complex query spanning multiple tables, and you'll wish you used SQL. Usually the best approach is a combination....

Even though DB_DataObject has an ok query interface, I agree that eventually they are going to need to be writing some sql. It's just unavoidable, but my guess is that this will not happen very often. When the time came, if DB_DataObject couldn't handle it, my plan was to toss them up to the pear:Db level. This is a generic database interface similar to perl's dbi which is only slightly better than mysql_* functions.

Thank you for the link to Ibatis. It looks fairly slick. I don't really think these guys could ever handle java/.net style development, but I might give it a go sometime. Again, thanks.

> Now when I see a newbie book teaching people to pound out their own sql and use old school mysql_connect style functions, I question my judgement. Is it a good idea or a bad idea to try to introduce these kinds of rapid development tools to novices? On one hand, these tools make my life easier on a daily basis. On the other hand, sometimes it's better to know the basics before going off to advanced topics like this. What do you guys think?

Object oriented data access layers can sometimes be useful - but sooner or later you're going to do a complex query spanning multiple tables, and you'll wish you used SQL.
Usually the best approach is a combination, and if you design your data access layer correctly the SQL vs ORM decision doesn't have to be system wide.
If you're using Java or .NET, then a tool like iBatis seems to be just the right balance between power, abstraction and simplicity. I don't know if something similar exists for PHP.

Abstracting the database is ALWAYS a good thing. Books teaching the use of the mysql_* functions in PHP are simply WRONG, and should not be allowed to be sold. Those books are responsible for every slashdotted and vulnerable PHP site on the net, and contribute to the lack of good design principles.

The good news: Apache Geronimon. Free, documented. 'nuff said.

More good news: Spring framework, Hibernate, iBatis..

... And at the same time, in a tight job market, I, a perl/c/java developer is being `forced' (financially in need) to learn .NET, and do the next project using that...

I've heard about that too. Microsoft is giving up .NET to software houses almost for free in order to increase its market share. They don't realize the price will skyrocket once the monopoly is achieved.

It might be too late for you, but in fact a lot of opensource effort has been made for commercial J2EE alternaitves. Take a look at Apache Struts, Hibernate, Velocity, Eclipse and Easy Struts, etc. As a matter of fact the most expensive (and almost non-repaceable part) is the EJB containers which is included in the most expensive J2EE component - Application Server. With all the opensource alternatives out there I think the cost J2EE deployment will be drastically lower in the very near future.

You can take a look of the example 'PetShop' reimplemented with MVC-based Struts here.

Only you've to get familar with the tools so as to recommend it to your boss with confident. That's what I've suggested to the friend I mentioned in the parent post.

While I think I see your point about architecture, I would argue that it is up to the developer/architect to choose an architecture that makes sense...

Spot on. Regarding the Java Pet Store example used above, there's an alternative implementation that might be more appealing to people who preferred the .NET implementation to Sun's (including myself).

The purpose of Sun's Pet Store was to demonstrate "best practices" (not performance, which is why the more performance-oriented .NET store smoked it). Unfortunately, they layered best practice on top of best practice until all they had left was a completely bloated mess.

Oracle has their own implementation as well, which I believe is also competitive with the .NET store.

• http://www.ibatis.com/jpetstore/jpetstore.html
• http://sourceforge.net/projects/petsoar
• • The problem is that even if they fix it, they will not get the adience like the report from the Middleware Company. They really did a great deal of damage on J2EE, and I have the feeling that they will regret it.

Here's the basic story.

Once upon a time, Sun wrote a sample application, called PetStore, as a demonstration of various capabilities of the J2EE platform, and various techniques that might be helpful when writing J2EE applications. As such, it was deliberately over-engineered. A tiny shopping site doesn't need all the techniques they threw at it, it was just a context in which to deliver examples of coding pratices that might be useful in other situations. It was example code.

Speed wasn't a goal. Keeping the LOC low was counter-productive to an application which is basically an example of different coding techniques.

Microsoft saw this, and realised they had a cheap marketing opportunity. By rewriting the Pet Store in .NET, with completely different goals (speed and low LOC), they could score points just by issuing press releases. It's the marketing equivalent of saying "Hey! Our car is smaller and faster than your truck!" It's true, but meaningless.

No matter that it was an apples to oranges comparison. No matter that the Pet Store could be rewritten in Java using Open Source frameworks with about the same number of LOC by one guy in his spare time. This is marketing, not reality.

Charles Miller

It is interesting to see how the funding of benchmarks/reports can impact the outcome.

Look at Ibatis JPetstore to see what one guy did with jpetstore in response to the .net version and its over inflated LOC difference.

When looking at his example and documentation you can really see how easily you can sawy one of these benchmarks/reports.

The original J2EE version of the Petstore application was meant as an EDUCATIONAL example for those new to J2EE. As such, it was not built with performance in mind, but rather was built with the mentality "How can we use every aspect of J2EE to implement this incredibly simple problem." No one in their right mind would use J2EE or EJBs to implement the Petstore app. It would be overkill in the extreme. And even if the J2EE version of the Petstore app was modified for performance, it's unlikely you'll be able to beat something that was built from the ground up with performance issues in mind. I'm sure this was the case with the .NET version.

If you want a good comparison of a .NET and Java version of the Petstore app, check out JPetstore which was built from the ground up with simplicity and performance as high priorities. Hopefully in the upcoming weeks we'll see some good benchmarks using this version instead of the J2EE version.

That's funny... that's the polar opposite of this graph.

Bah, but who really cares? Hell, I actually own a pet store, and I use neither of these. A simple off-the-shelf system works great for me, and speed isn't an issue. I don't give a rat's ass what it's written with, as long as it works. Just like I don't care whether the parts in my stereo came from China or Taiwan, as long as it works.

jPetStore is worth checking out. These people decided that the J2EE pet store is way too complex, which I'm inclined to agree with. They produced, using Jakarta Struts, a Java pet store web application that is much leaner. It's comparable in size to the .NET pet store but better in several ways - there's no SQL embedded in the code, there's no HTML embedded in the database, no code was automatically generated, and it's MVC-based.

I've always thought that Enterprise Java Beans are overengineering to the extreme. It's nice to have something to back that up with now. There's no question in my mind that this JPetStore beats out both the original J2EE one and the .NET one in maintainability.

They didn't do any benchmarks - performance wasn't what they were going for - but it would be interesting to see some. I'd be inclined to believe this simpler approach would also have much better performance than J2EE.

the big question begging moving from a simple jsp/servlet engine like Tomcat/Jetty/Resin to a full blown J2EE app server like WebSphere/BEA/JBoss is Do you want to run EJBs?
i'm not an expert on EJBs by any means, and i'm trying to ask this same question of my own projects, but what i keep hearing is this: EJBs allow me to run much more scalable than servlet/javabeans.
i dont know what your prospective usage numbers are, but if they are large scale (aka site on the internet that loads of people will hit hard) then you want to use an EJB architecture because you will be able to scale up with lots of big servers. given that you are working on PCs, my guess is that this is not the case.

Also, i keep hearing that utilizing an EJB App Server will bring with it database connection architectures like Container Managed Persistance etc. BUT... there are some great examples of utilizing other data access patterns like Data Access Objects (see the jpetstore example)

i think it comes down to proper application architecture. make sure your applications have good design, and keep in mind scalability (especially with the data access bottleneck) and you should be ok.

oh yeah... in favor of tomcat ... Tomcat is used by IBM WebSphere to run all the jsp and servlets in webSphere, which in turn can then utilize the EJBs...