Using Value Objects

Hi,

I like the concept of value objects it is simplifying the design and making it consistent and error resistant.

BUT

Let say i have several Entities where i store some person related data like Users (for application users) Clients  and Employees ( they are the contacts of Clients)

all of those 3 entities has a valuobject of type Person

class Person

{

FirstName 

LastName

Email

Phone

Fax

}

So I have 3 pretty entities but because the immutable feature of Value Object it is simply tooo hard to make them working in a CRUD screens and grids. 

Is there any clue or trick  to fast and easy way to scaffold those entities because I feel that i'll pay too much price in terms of time because I using that feature. 

I cannot simply build a CRUD screen because i'll have a proxy class to fill the value objects property, I cannot have a grid column on those fields and have an inplace editor working... and so on.

Please tell me that I am doing something fundamentally wrong and there is a easy way to use them. Otherways I think I'll not use them. 

(I need scaffold fast CRUD screens and grids for 20+ table all of them have value object property some of them several different one)

Regards

Sandor

Designer-generated value objects don't play nicely with 'widget per field' scaffolding.  If you want to use that kind of scaffolding, then you probably won't be able to use value objects.  Depending on how you are scaffolding, though, you may be able to create a "Person Editor" partial or user control and map that to your Person type.  Your PersonEditor would return new Person values just as a text editor returns a new String or a date-time picker returns a new DateTime -- such is the nature of value types.

You can also opt out of the designer-generated code and implement mutable value objects, which would play better with scaffolding, but would need some thinking about dirty notifications (a value object can't call Entity.Set so a value object property setter can't directly mark the containing entity as dirty).

That said, in your specific case, I'm a bit doubtful about whether Person really should be a value object.  It sounds more like User, Client and Employee are kinds of Person, so concrete table inheritance could be a better way to map them.  Or if a Client is not a Person but may refer to a Person (e.g. the primary contact), then an association could be in order.  In any case, Person sounds like it has identity and is therefore a strong candidate for being an entity rather than a value object -- just a suggestion!

Thanks for the answer.

I try to describe my case better.

Yes the value objects are good when it is a User Defined Type (money = Decimal), but they are worse when they are class like objects like in my example.

In my example there are several entities. 

Client: 

It is a company, legal entity it have several properties for that reason for example TAX number, registered address, office etc.

Provider: 

They are providing services to the Clients, they are firms too.

So the natural thinking is Lets make a Firm entity and inherit from it the client and provider entities.

But They must be in two  separate table. And the client has several Provider related many to one links like Client.Accountant, Client.Lawyer etc which are Providers

Even worse every firm like entities has several Person type properties. Like contacts, Managers, Employees, Personal Assistants etc

So to make the design cleaner and faster I made Value Objects for FirmData, Person, GeoLocation every one of them have several properties.

But right now it seems that only overcomplicating the code even when the design is nice and pretty.

Regards

Sandor