Cameron Wallace McKenzie wrote:Just avoid persisting value objects, and instead, only define core model classes as entities. Problem solved!
-Cameron McKenzie
Data transfer object (DTO), formerly known as value objects or VO, is a design pattern used to transfer data between software application subsystems.
Cameron Wallace McKenzie wrote:
Are these really value objects, or are these all part of your core domain model? Price is really a core element of your domain. I don't think it's a value object, right?
-Cameron McKenzie
Cameron Wallace McKenzie wrote:One approach would be to create a private constructor and even some private setters for the variables. Hibernate needs a constructor, but it does not need to be public, so it will be shielded from the world.
-Cameron McKenzie
Cameron Wallace McKenzie wrote:I think Hibernate will save it even with the final variable. The data is still there.
Give it a try and see if you get any errors.
Cameron Wallace McKenzie wrote:I'd be interested in seeing the exact problem. final variables can be persisted by Hibernate, I do believe. Obviously you have a challenge of initializing them some place, but doing it in a private constructor would suffice. So, with that tweak it should work. (You may need to add a private setter/getter, where the setter does nothing.)
I'd be interested in any exceptions or error messages that elute.
Good luck, and keep asking questions, Greenhorn!
-Cameron McKenzie
Obviously you have a challenge of initializing them some place
the fact that new BigDecimal() does not exist
is called and that later some real value for the BigDecimal will replace the bogus one?
Cameron Wallace McKenzie wrote:
It has to get initialized at some point. The code you currently have must initialize it at some point. When does the current code do it? Just do it the same way.