• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

[absolute beginner] what do to with value objects

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all

I have some java classes that yield "value objecst" with immutable final fields (initialized by constructors)
a friend of mine tries to use those in a JEE context and tells me he has a problem
since persistence may require some no-arg constructor
well:
- I know next to nothing about JPA and other tools (I practice only standard Java)
- being stubborn I will certainly not change my code (I have serious reasons to have such codes)

my argument is that such objects should be handled differently (+ most are not entities at all)

so what strategies would you recommend ? (what is simple, what is efficient, other considerations ...?)

thanks



 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just avoid persisting value objects, and instead, only define core model classes as entities. Problem solved!

-Cameron McKenzie
 
bernard amadeus
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Cameron Wallace McKenzie wrote:Just avoid persisting value objects, and instead, only define core model classes as entities. Problem solved!

-Cameron McKenzie


urrgh? me puzzled
as an example :
if a "Product" has a "Price" (which is a value Object) how do you persist the price of the Product?

 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, a value object is used to transfer data between subsystems.

Data transfer object (DTO), formerly known as value objects or VO, is a design pattern used to transfer data between software application subsystems.



http://en.wikipedia.org/wiki/Data_transfer_object

Sun Value Object Design Pattern

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

 
bernard amadeus
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


I will not argue about the christening of the thing .... just as an example a Product has a Price (implemented as a special class).
members of Price are final (and should be for different reasons ... again beyond my question)
now how do you design the persistence of Product ?

 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
bernard amadeus
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


a private constructor for Price?
but since members are final you will be unable to create Price() ?

I suspect that in such cases of "values" (Oops sorry escaped me ) the columns of Price get added to the colums of Product ....
how do you do that properly while having final members?

 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 McKenzie
 
bernard amadeus
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


well I don't touch powerful magical wands ... only my friend does .... and must use JPA.
does not work there.

edit: but I am interested by the theoretical aspects of the question !
 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
bernard amadeus
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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



urgh how would you design such a constructor ? :


Very green Horn!

 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You simply initialize the fields in the constructor.

Obviously you have a challenge of initializing them some place



As I said, you have the challenge of 'when' to initialize the final fields. Do it in a static block? Do it in the private constructor? Do it as they are declared? How do you do it now?

But indeed, the field needs to be initialized at some point. Doing it in the private constructor would work and eliminate the compile error.



(Nice Horn )

-Cameron McKenzie
 
bernard amadeus
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
let's skip pesky details such as the fact that new BigDecimal() does not exist ... what is to be expected?
that the no-arg contructor is called and that later some real value for the BigDecimal will replace the bogus one?
strange!
after all the Serialization mechanism does handle this pretty well so why persistence mechanisms have to be byzantine?
 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

the fact that new BigDecimal() does not exist



No package declaration was specified. com.cameronmckenzie.BigDecimal has a default constructor, so there!

is called and that later some real value for the BigDecimal will replace the bogus one?



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.

-Cameron McKenzie
 
bernard amadeus
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



well, as described before, the initialization takes place with the "normal" constructors (two args at least!)
since both instance members are final they have to be initialized by every constructor.
since java.util's BigDecimal and Currency have no default constructor you can only build the object by providing correct arguments to the
constructor (let's say two Strings, or two Strings and one Locale).

So let's summarize again:
- here we have an Object which is part of the persistent state (though not an entity)
- there is no way to have a no-arg constructor (or fancy "setters")
- for other reasons I am NOT going to change the final status of these members (hey aren't we supposed to use normal objects?)

now what is the theory behind the use of such objects ? there has to be something since this kind of situation is common
(when you use value objects ... OOops the term escaped from my keyboard )
- again Serialization does it no questions asked ... for sure persistence addresses different problems (such as lazy loading of values)
but the loading of such a "value" (Ooops again!) could be declared atomic, in fact tools do this for BigDecimal why not for user-defined
classes?
 
bernard amadeus
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well, well, come on experts! greenhorn only hears silence
I know I often ask questions that are not mainstream and so I get only puzzled looks
what could look "logical" for me :when an entity has a field which is a value object the fields of this member
are uploaded from the base and the correct constructor for this member is called (introspection at this level is not extraordinary difficult).
Is there something for this in JPA and implementations?
 
reply
    Bookmark Topic Watch Topic
  • New Topic