MVC2 Poco Update when properties are not mapped to View Model

I'm after some opinions \ best practice for handling updates to my repository in the following scenario:

I am using EF 4 with the POCO tt templates which creates nice clean clr objects. For example's sake lets say I have a POCO object name Customer and a ViewModel called CustomerViewModel. CustomerViewModel has a public property for the Customer object which is populated with the POCO Customer object.The view references the Customer object on the CustomerViewModel. So far so good. Everything is displayed as expected.

When it comes time to update the CustomerViewModel is passed back and only the properties that were bound to the view are populated, fair enough.

What I have now is a POCO object that is missing some of the property values which are needed to update via the EF data context. For example, since I did not display the ID in the view, it was not hydrated back into the view model's Customer property. Not really surprising behaviour but I am wondering what the best way to handle this scenario is.

So here is the question: Would it be better to map the properties that i don't display into hidden fields so that I have the complete POCO object on postback which is ready for updating to the Repository? (I'm thinking there is needles sending of data to and from the client here)

OR should I do a read of Customer before my update(assuming I have the ID) and then update the properties from my view model object. ( is this a needles read on the database ?).

OR is there another may altogether that I am missing.

I realise that maybe there is no one correct answer 开发者_如何学编程for this but I'd be interested to hear how others are handling this scenario.

Thanks

I'm going to answer my own question here... maybe it was a silly question but the act of writing it out has made the answer more obvious..

The first option of populating hidden fields is a bad idea for too many reasons!! So I think I'll have to go with doing a read of the customer object on the post back and calling.

TryUpdateModel(customer, "Customer");

Where customer is the freshly read Customer and "Customer" is the property name on the view model.

It seems that this results in more data access than in a classic ASP where the object could have been shoved (rightly or wrongly) into Session !

Anyone care to add their 2c ?