This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Object Relational Mapping and the fly likes [absolute beginner] what do to with value objects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "[absolute beginner] what do to with value objects" Watch "[absolute beginner] what do to with value objects" New topic
Author

[absolute beginner] what do to with value objects

bernard amadeus
Greenhorn

Joined: May 15, 2009
Posts: 21
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



Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968

Just avoid persisting value objects, and instead, only define core model classes as entities. Problem solved!

-Cameron McKenzie
bernard amadeus
Greenhorn

Joined: May 15, 2009
Posts: 21
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
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968

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

Joined: May 15, 2009
Posts: 21
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
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968

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

Joined: May 15, 2009
Posts: 21
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
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968

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

Joined: May 15, 2009
Posts: 21
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
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968

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

Joined: May 15, 2009
Posts: 21
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
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968

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

Joined: May 15, 2009
Posts: 21
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
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968

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

Joined: May 15, 2009
Posts: 21
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

Joined: May 15, 2009
Posts: 21
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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: [absolute beginner] what do to with value objects
 
Similar Threads
Passing objects w/ JNI
Pass by value & pass by reference data types
Use of value objects in your EJB apps
Doubt in UML distilled by Martin Fowler page 94
What is the purpose of a final instance variable?