In ASP.NET MVC, should the view models have an ID?

Question

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; }
}

Answer 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.

Answer 2

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.