I've been going back and forth on the following issue for sometime now but I'd like to get some different opinions. For all of the applications I deal with my java objects do not match up with my database tables nor should they and alot of the differences revolve around Internationalization. Because of this I have two real options, I can create objects that meet both the hibernate and application concerns there by coupling them together. Or I can do what I believe is the appropriate thing and use the hibernate objects simply as data transfer objects and use business layer classes to transfer the data thereby creating a true seperation between my model and the rest of my app.
Does anyone out there have any suggestions or comments on the class organization of these types of apps (usually struts and hibernate) and the difficulties inherent in ensuring that they remain decoupled?
Internationalization... for example, lets say we are dealing with food. That food is organized by Food group and sub group. The food, group and sub-group have different values depending on the language but you want the user to be able to transfer between one language and another so the ID for a food is the same regardless of the language. As a result you have an ID, and the food name in as many languages as you need as a row in your DB. As a hibernate object (as far as I'm aware) you have all those languages present however as a Java object you don't care what language you're using as your food has a name and it's the responsibility of the business layer to populate it according to the Locale. Picture using a POJO in your jsp tags, you want to call name not englishname, frenchname, germanname, etc. depending on what the locale is as that logic is not the role of the jsp page.
This seperates your view and controller POJO's from the details of language implementation and isolates where changes need to be made if new ones are added. In my mind a business class will take the data from a hibernate object populate a POJO depending on the Locale (plus other items) and pass that POJO back to the calling struts action (which puts it in session for the jsp to use). At this point you can change the data access implementation (jdbc, ejb, etc) without altering anything for the struts and up just the business classes.
My question is, is that a reasonable way of doing it? I don't want to end up with my layers to reliant upon each other where one change will affect all portions of the application. I'm just not certain that that is a better way of going about it (or is there something that I'm completely missing that hibernate can accomplish).