11

When developing an ASP.NET MVC application that allows the model to be updated, you need some way to know how to take the updated view model and match it back to the model that is now updated. There seems to be a few different ways of doing this and I'm wondering if any of these are not proper MVC (much like having your controller store data that should be in the model is not proper MVC)?

All View Models have an ID: Pros

  • Always ensure you can match to your model.

Cons

  • You have to be real careful that none of the IDs were changed else you can have users updating rows they shouldn't have access to.

Only the bare minimum view models have an ID: Pros

  • Far less checking needed to avoid users updating data they shouldn't access.

Cons

  • Far more difficult to track what view models matches what model.
  • You still have to check the few view models with IDs to make sure the user isn't updating data they shouldn't have access to.

No view models have ID:

Pros

  • No need to check IDs for updates.

Cons

  • You have to abandon statelessness.

So I have two questions.

First, is there a correct/incorrect choice? (If not, that means the choice is a matter of opinion and my second question opinion based and should be ignored.)

Second, if there is a correct/incorrect choice, which is it?

To clarify on a comment, I'm talking when you have a view model that is a mimic of your database object.

Think this:

public class InvoiceViewModel  //Does not have ID, does not relate to model.
{
    public CustomerViewModel CustomerVM { get; set; }  //Maybe has ID?  Does relate to model.
    public AddressViewModel BillingAddressVM { get; set; } //Ditto
    public AddressViewModel ShippingAddressVM { get; set; } //Ditto
    public List<InvoiceLineItemViewModel> ItemVMs { get; set; }  //Each one has an ID?
}

not this:

public class InvoiceViewModel
{
    public Customer Customer { get; set; }
    public Address BillingAddress { get; set; }
    public Address ShippingAddress { get; set; }
    public List<InvoiceLineItem> Items { get; set; }
}
  • 2
    What exactly would you do with a ViewModel ID? Don't the individual objects in the ViewModel have their own ID's anyway? – Robert Harvey Oct 16 '14 at 16:42
  • I should probably specify only when the view model is related to a model. Not all view models are related. – Lawtonfogle Oct 16 '14 at 18:06
  • You have to abandon statelessness. - You have just made the choice to use MVC pointless. – Joel Etherton Oct 16 '14 at 22:30
  • Is the ID you are referring to here a database primary key, or something else you are adding to the ViewModel? – Vermis Oct 21 '14 at 14:26
  • @Vermis, I think that a database primary key would be a simple ID. A more thorough ID would be any non-modifiable piece of data that allows you to relate your edited object back to the not-yet-edited persisted version so that the edited changes can be persisted. – Lawtonfogle Oct 21 '14 at 19:27
1

The ViewModel object is not what gets stored in a database table, generally. It's the individual items in the ViewModel object that get stored. Each of those items already has an ID.

For example:

public class InvoiceViewModel
{
    public Customer Customer { get; set; }
    public Address BillingAddress { get; set; }
    public Address ShippingAddress { get; set; }
    public List<InvoiceLineItem> Items { get; set; }
}

Since there's no single table in the database that corresponds to an InvoiceViewModel, there is no ID for an InvoiceViewModel object.

Of course, you can always use the InvoiceID as the id for this particular ViewModel. InvoiceID is handy, because that's what this object ultimately represents. But I could see having a ViewModel object that doesn't correspond to any particular ID in the database.

  • 1
    Think where instead of using the actual models in the view model, InvoiceViewModel contains only other view models (which related to models). – Lawtonfogle Oct 16 '14 at 18:15
-1

By default you should have an id in view even though you are not using it. Create a column in database named as id and tick the auto increment feature over it so you will be sorted.

  • 1
    This directly contradicts the other answer though, without addressing why you should have an id anyway. – Martijn Pieters Jan 14 '15 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.