views:

196

answers:

4

We have a simple domain model: Contact, TelephoneNumber and ContactRepository. Contact is entity, it has an identity field. TelephoneNumber is typical value object: hasn't any identity and couldn't be loaded separately from the Contact instance.

From other side we have web application for manipulating the contacts. 1st page is "ContactList", next page is "Contact/C0001" which shows the contact details and the list of telephone numbers.

We have to implement telepone numbers edit form. The first approximation thought is to add some page which will be navigable like 'ThelephoneNumber/T0001'.

But ThelephoneNumber is is Value Object class and its instance couldn't be identified this way.

What is the best practice for resolving this issue? How can we identify non-identifieble objects in the stateless applications?

+2  A: 

Does the value objects state identify that particular instance? If not you could just pass back the old value and the new value when the edit form is submitted, then update any objects with the old state to the new state.

I would rather have a page like Contact/C0001/ThelephoneNumber, and use both the contact id and the value objects class to identify the instance you want to change.

Unless I've completely misunderstood what you're asking.

Marc Gear
Well, the Contact contains many TelephoneNumbers. And I need the form for editing 1 of these numbers.I see here only one way: to use URLs like Contact/C0001/ThelephoneNumber/21, where 21 is index in the kind of FixedOrderList of TelephoneNumbers within the Contact #0001.But I dont like this idea
noetic
Well if the only way to identify that numbers instance is by its state, then you'll have to use the old/new state method outlined above. Although that won't be possible if more than once contact can share a phone number. I'd consider making them entities.
Marc Gear
A: 

I would make the TelephoneNumber just contain a bunch of numbers (maybe make it plural), and refer to it this way: Contact/C0001/TelephoneNumber(s)

auramo
A: 

In practice I always find it easier to give the telephone number an identity, even if it isn't strictly necessary in design terms.

If it is a strict value object which cannot exist outside the context of the Contact, that indicates that a good user interface may call for the telephone number to be edited within the contact page rather than on its own page.

However I think Marc Gear's solution is a good one if you decide against either of those two approaches.

Leigh Caldwell
A: 

Despite what many people would like you believe, you can't be 100% pure.

Your value objects need some kind of Identity field. Sometimes it will be something unique for an object like a phone number, sometimes it will have to be something artificial, like TelephoneNumber.Id.

The sooner you accept this, the better for you :-)