Todd Huss

I had a chance to play with Hibernate and Middlegen this afternoon for a few hours in preparation for doing a Hibernate workshop with some programmers at work. My preference has always been to design my database schema and then generate the ORM layer on-top of that. I guess my reasoning is that the database is the heart of any large application and in many cases will have a web-app running against it, a 3rd party reporting system, an automated emailing system, etc… so it feels unnatural to me to use my web-app codebase to generate the schema.

This article on Hibernate's website got me started with Middlegen. After mucking with my ant build.xml I had Middlegen and Hibernate's hbm2java generating my hibernate mapping files and java domain model. Not bad.

Next I created some DAO objects and respective JUnit tests to play with some Hibernate queries to fetch my domain objects. For simple stuff QBE (Query By Example) is by far my favorite since it in no way ties you to an ORM suite and is the most object oriented looking approach to simple querying (to me atleast). HQL is also simple (and of course familiar) for doing joins and other more involved queries. I have the least experience with QBC (Query By Criteria) so I tend to stick with HQL. I guess with QBC I find myself translating it to an SQL like syntax in my head anyhow so HQL just feels more natural.

Next I want to try adding Spring into the mix for IoC and to get the benefit of Spring's generic unchecked exception hierarchies so I can stop polluting my DAO's with all of those try/catch blocks that are only there to catch unrecoverable errors anyhow. My take is, if it's not a recoverable error than the exception should be unchecked. That way I can catch it if I want but otherwise it will go right up the call stack without me having to declare it everywhere.

Just finished Rod Johnson’s excellent and very accessible book Expert One-on-One J2EE Development without EJB. What I think this book does best is provide one with a good introduction and overview of:

• IoC containers
• MVC frameworks
• OR Mapping
• Unit testing (covers Mock objects as well)
• AOP
• Vertical versus Horizontal scaling

Having taken a 2 year hiatus from Java (and EJB) programming, I came back to find the java architecture/framework landscape vastly improved but with a lot to learn (namely IoC, MVC beyond Struts, AOP, and Unit testing). I was also thrilled to find a good open-source OR mapping alternative to Toplink and Cocobase (the latter of which I used for 3 years). This is the 3rd book I’ve read on these topics and so far my favorite!

I hate having to test a site on multiple versions of Internet Explorer, not to mention my general dislike for IE as a browser. Anyhow, up until today, I’ve known which machines in our office have older versions of IE so I can use them to test.

No more! I discovered Ryan Parman’s site where he has created standalone IE. You just download the version of IE you want, unzip it, click ieexplore.exe, and you’ve got that version running and it doesn’t conflict with your installed version of IE. Great work Ryan!

I’ll have to try this out with Wine on Linux and see if it works…

I found this very informative thread over on the serverside with the authors of Hivemind and Spring discussing the differences in their approaches. Scroll down past the hivemind announcement for the juicy stuff:

http://www.theserverside.com/news/thread.tss?thread_id=28937

I would sum up the differences (and I'm interested in others opinions here) as follows:

Hivemind

• Configuration: has better support for strongly typed configuration with its excellent configuration point schema support. Spring only supports this via Map, List, and Properties.
• AOP Interceptors: has a less verbose syntax for configuring interceptors which I find more readable and correct (not directly exposing the target) than Spring's
• Hivedoc: a great way to visually see how all your dependencies wire up

Spring

• 3rd party support: Hibernate, iBatis, Struts, Transaction management, etc…
• Generic exception heirarchies: for example for data access
• Large user base

Every good web programmer knows the tradeoff of a GET versus a POST request. If you want a user to be able to bookmark a page that takes parameters the GET request is the way to go. If it’s a one-time form submission (especially one that causes data to change in the database) the POST request is your only choice.

This was made especially evident while we were debugging some ancient perl code the other day. Basically it was a page on my company’s site that let a user subscribe to a newsletter. It did so with your standard <form action=”foo.cgi”> and neglected to specific the method of GET or POST, so the browser of course defaults to a GET. Anyhow, we were seeing users getting signed up for duplicate copies of the same newsletter (which also pointed to a lack of proper database constraints).

So to test it we tailed the Apache access log on the dev server as we signed up for a newsletter. Rather than seeing just 1 hit to the signup script we saw 2. The User Agent string made it apparent, one was Mozilla (me) and the other was (Google Adsense). We do run adsense on the site and so for Google to figure out which ads to display on the page, it was hitting the same page we were with the same GET parameters causing the duplicate signup. Fortunately the test server we were using was outside our firewall where the Google Adsense bot can access it. Otherwise I would have had a really tough time reproducing the problem.

Anyhow, adding proper database constraints and switching it to a POST request fixed our problem but it was an interesting lesson. Before the days of Adsense you could often skate by with the sloppy combination of weak database constraints and forgetting to specify that a form should be method=”POST”.