0

This is a general concept question dealing with the Edit life-cycle in MVC.

As I understand it, the Edit GET action pulls the requested instance from the db context and ends by passing that instance to the Edit View (where the instance is referred to as the view model).

The Edit View uses stuff like this:

@Html.HiddenFor(model => model.SomethingIDoNOTWantEdited)
<div class="form-group">
    @Html.LabelFor(model => model.SomethingIDoWantEdited, htmlAttributes: new { @class = "control-label col-md-2" })
    <div class="col-md-10">
        @Html.EditorFor(model => model.SomethingIDoWantEdited, new { htmlAttributes = new { @class = "form-control" } })
        @Html.ValidationMessageFor(model => model.SomethingIDoWantEdited, "", new { @class = "text-danger" })
    </div>
</div>

to display some or all of the properties of the view model so that the user can change the values if needed.

When the user clicks the submit button the Edit POST Action is called, and when used with something like this

[HttpPost]
public ActionResult Edit([Bind(Include = "Id, SomethingIDoWantEdited, SomethingIDoNOTWantEdited")] MyClass viewModel)

Makes a bright shiny new object of type MyClass called viewModel.

Now, I know I could do a query on the context and get the current object in the db that has that Id, and then copy all the fields from viewModel to the existing one before marking the original as modified and then calling SaveChanges(). That's not too bad when there are only a few properties to copy, but when there are lots of them it becomes cumbersome.

Is there a better way to get the items the user changed written back to the database?

davecove
  • 1,001
  • 4
  • 16
  • 36
  • 1
    Your not understanding [What is a view model](http://stackoverflow.com/questions/11064316/what-is-viewmodel-in-mvc). If your getting an instance from the db context and passing that to the view then that instance is your data model. A view model is a separate class used to represent what you want to display/edit and often contains `SelectLists` and other properties used by the view. As for mapping properties between data and view models, you can use tools such as [automapper](https://automapper.codeplex.com/). ps. anytime your use `[Bind(Include..)]` reconsider what your doing. –  Nov 05 '14 at 01:52
  • Ok, bad terms maybe... MyClass already contains those SelectLists and [NotMapped] properties so MyClass does double duty as a ViewModel. As far as using [Bind(Include...)] goes, that is how EF did it when I had it generate my views, so I went with it. Can you elaborate a bit more on the usual way to get lots of data from the instance coming from the view and the one coming from the db inside the Edit POST handler? – davecove Nov 05 '14 at 02:00
  • 1
    Personally I think trying to have your data model _double as a ViewModel_ is bad practice (which is why I gave the link above). A few options are discussed [here](http://community.sitepoint.com/t/mvc-savechanges-doesnt-seem-to-work-with-passed-object/8683) –  Nov 05 '14 at 02:19
  • Understood, but when you have a model with 15 elements that need to be edited, and only needs 2 SelectLists, I think it makes more sense to add the SelectLists to the model than to add the elements to a separate ViewModel. Tho I am thinking of making a ViewModel class containing the SelectLists that then inherits the class with all the editable elements. – davecove Nov 05 '14 at 02:23
  • The 'EF's auto-attaching methods' solution on the page you pointed at was just what I was looking for. Post as an answer and I'll accept it. – davecove Nov 05 '14 at 02:40
  • No thanks, I try not to give poor answers. As it stated _This is a prime reason you don't pass entities to views_ and you should _convert the entity into a view model first_. Feel free to answer and accept it yourself. –  Nov 05 '14 at 02:47

0 Answers0