When you get over the learning curve, which is quite large, the mess doesn't exist. I've never seen an issue with hibernate which isn't caused by poor understanding. You really do have to know your shit before you start - you can't just waltz in django-style and write code. You have to think about session management strategies and architecture.
It has nothing to do with understanding and everything with having to create a bunch of excess code to deal with the way it works.
As an example: I shouldn't have to write a filter to wrap the template rendering stage of request processing in a transaction just to make lazy loading work.
To make hibernate useful you almost always need to have another framework manage it (SEAM, Spring, etc). I'm not going to use an ORM that requires an entire other framework just to make it reasonable to work with.
Hibernate also has the worst query building framework I've seen. Its far and away the most verbose piece of crap I've ever worked with. As a result most people just drop to writing queries in JPL which removes one of the big niceties of an ORM.
Well you've conclusively proven my point because its obvious you don't know how to use hibernate properly.
You never lazy load stuff from a view. That is a recipe for disaster. You use a projection or set of projections and populate your model up front. The transaction should be concluded way before the view is rendered. If you get that wrong, your architecture is broken.
The only bit of infrastructure we use is an annotation + AOP which wraps a service method in a transaction and unit of work. This is all container managed. To be honest, it's literally 3 lines of config and works universally.
Verbosity - that's a load of crap. We have 3 lines of AOP config, a mapping file per class and nh config which is about 12 lines of XML. All the config was cut and paste.
The whole thing gives us a model which is portable between engines, proper transaction management, cache layer, schema generation, fully testable data API (we materialise the whole model into HSQL in integration tests) and documentation which is actually good.
It's a no brainer. I suggest you go read POEAA and have a think.
Sounds like a complete mess and I see no reason to build an application that way. I certainly can't see a reason to create a separate query for every place in a view a model may be used just to avoid lazy loading. Maybe on performance critical views but the rest of the time, that is an unneeded premature optimization.
You've also proved my point, by needing an entire 'container' managing things to keep everything straight. I'll happily keep hibernate in my rear view mirror, I'm quite happy with Ebean.
