OOHHHHH. Applications where there are no "domain" objects to map the relational model to. So why did you ask "what" earlier for?



But again and again I see people create a class with nothing but private variables and getters and setters in order to hold rows of data from a table.



Probably cause they thinking DTOs. But to be honest, having things in a bean is much better than passing recordsets around and dealing with them in their raw format EVERYWHERE. Been there. Done that. The same goes for XML, at least the dealing part.

Yeah. Wouldn't want to code anything in an application. :) Seriously, how does it limit you?

The phrase "What would like like to apply it to" doesn't make sense to me. As a prolific typoist I would normally try to interpolate but I am unsure of what you meant. My best guesses don't make sense to me in the context of our conversation.I find myself maintaining an application that executes a stored procedure and maps the result rows into a bean. Then the bean fields are written to xml and the bean is garbage. The bean is completely extraneous. It adds no value and means that every new implementation of this kind of operation will require some code to be written and deployed.We have another application in it's second design cycle. The idea is to create a consistent interface for users to configure the hundreds of tables containing codes and options and other business specific things that change all the time. The original implementation uses Cayenne, which is like Hibernate, just crappier. One of the main goals was to make it very easy to create new screens because the development team has has been bogged down with the maintenance of these tables and their interfaces. The problem is that Cayenne requires a new class for each screen and a bunch of XML and other developer tasks. In effect, Cayenne defeats much of the purpose of the tool. Now we are in the second design and I believe it will be built on Hibernate. I don't really see that the fundamental issue will be solved. Unless I'm mistaken, you still need at at least a bean (just like Cayenne) and usually some XML. I developed a prototype of an application to do the same thing where new screens did not require any new code. The screens were added purely through configuration. But we are not going with that approach because Hibernate is what is used to develop Java database applications. As to the rest of your response. I'm not sure what you are arguing about. Hibernate has a specific problem space that it fits into well. My point is that it's considered a one-stop solution for any database connected application. Any suggestion that this is not the case goes against what I see on a daily basis. I think there are many Java developers who already cannot write a Java database application without Hibernate and the numbers will surely grow.