Question

I am using EF code first in one of my mvc 3 projects. I have a question about what patterns to use when passing a complex EF POCO object to and from the views.

For example, a customer object has a list of orders and each order has a list of items. The customer object will be sent to the view. The view updates the customer object and its inside objects (orders, items), then send it back the controller. The controller have EF to persist the customer object.

My questions are following:

1. Should I serialize the EF poco object to a JSON object so I can use it inside the view?

2. How can I re-construct the customer object when I recieve updates from view?

3. After the customer object is reconstructed, Is it possible to save the entire object graph (customer, orders, items) in one shot?

Thanks

Answer 1

1. Should I serialize the EF poco object to a JSON object so I can use it inside the view?
   No.
2. How can I re-construct the customer object when I recieve updates from view? Don’t. Let the default modelbinder materialize the POSTed data into a viewmodel (or editmodel), and use that data to issue commands to a lower layer.
3. After the customer object is reconstructed, Is it possible to save the entire object graph (customer, orders, items) in one shot? It is, but you shouldn’t. Instead, deal with each update individually based on your use cases.

Follow mojo722 and Pluc’s advice here. Don’t use EF POCO entities in your MVC layer. Use viewmodels. Here’s how it would work:

• Controller needs data, it asks a lower layer. The lower layer gets the data and returns entities (or better yet, entity views).
• Controller converts entities to viewmodels (AutoMapper is good for this, but you can map manually as well).
• Controller passes viewmodels to view.
• View sends HTTP POST data from HTML form.
• Default model binder converts HTTP POSTed form data to a viewmodel.
• Controller receives viewmodel data, issues a command to the lower layer.
• Lower layer uses EF to save new entity state.