The value objects are not simple attributes of an entity. Let me explain what they do (a little simplified but the fundamentals are there).
We have a research module that performs pricing research. ResearchItem CellPhoneResearchItem IPodResearchItem LaptopResearchItem Etc Since the identity of these research items is defined solely by their attributes they are implemented as value objects. I know this is different from your everyday value object (eg Address) Does this sound like maybe a problem that should be addressed in the domain model? Value objects were chosen since it makes it much easier in many other areas to just create a new research item, rather than call repositories to load old ones (impossible in some places). No point in loading something you know all the attributes of. The only way to get them reliably is to call ResearchItemGenerationService.generateResearchItems() -----Original Message----- From: James Carman <jcar...@carmanconsulting.com> Date: Wed, 11 Nov 2009 00:10:15 To: <users@wicket.apache.org> Subject: Re: another serialization question Can you go through the entity to get to these objects? Meaning, can you set up and LDM to get the "root" entity object and then traverse to get to the value object you're interested in? If so, then you can try to come up with some property "path" to get you there and use that to refer to the specific value object you're wanting to edit/view. On Tue, Nov 10, 2009 at 11:46 PM, Sam Barrow <s...@sambarrow.com> wrote: > I cannot make them serializable I don't have control over them. But even if I > did I couldn't because the valueobject has a reference to an entity which > cannot be serializable. The project also uses db4o which would make it much > harder to use a serialized version. > Is dtos the best/only way? It would be a very awkward design because I have > to both deal with subclasses of valueobject and converting the objects back > when calling the service layer > > > > ------Original Message------ > From: James Carman > To: users@wicket.apache.org > ReplyTo: users@wicket.apache.org > Subject: Re: another serialization question > Sent: Nov 10, 2009 11:39 PM > > Are you designing these value objects from scratch? Do you have > control over them? Then, why are you averse to making them > serializable? If you have a valid reason to not make them > serializable, then why not go with the DTO pattern and just figure out > a way to copy the attributes back and forth between your value objects > and your DTOs? > > > > On Tue, Nov 10, 2009 at 10:17 PM, Sam Barrow <s...@sambarrow.com> wrote: >> But some the ValueObject classes contain a reference to an entity. >> Keep in mind I mean ValueObject in the context of domain driven design, >> not a DTO / data transfer object. >> >> On Tue, 2009-11-10 at 22:12 -0500, James Carman wrote: >>> ValueObjects (if you're following the design pattern) should be >>> serializable. >>> >>> On Tue, Nov 10, 2009 at 10:03 PM, Sam Barrow <s...@sambarrow.com> wrote: >>> > >>> > One more question about serializing objects. >>> > I have a page in the application that I'm working on that calls an >>> > application service which returns a collection of objects of a type I'll >>> > call ValueObject (not serializable). ValueObject has many subclasses >>> > (which are of no concern to my wicket ui, which only deals with the >>> > ValueObject interface). >>> > >>> > So i have a page which calls the service and now has a collection of >>> > ValueObjects. What is the best way to pass this object to another page? >>> > Keep in mind it is not serializable and has no identity i can look it up >>> > by >>> > >>> > >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> > For additional commands, e-mail: users-h...@wicket.apache.org >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org