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

asp.net-mvcmvc

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

Best Answer

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.

Related Solutions

ASP.NET MVC – Separating Data Access in ASP.NET MVC

Generally, you want your Controllers to do only a few things:

Handle the incoming request
Delegate the processing to some business object
Pass the result of the business processing to the appropriate view for rendering

There shouldn't be any data access or complex business logic in the controller.

[In the simplest of apps, you can probably get away with basic data CRUD actions in your controller, but once you start adding in more than simple Get and Update calls, you are going to want to break out your processing into a separate class.]

Your controllers will usually depend on a 'Service' to do the actual processing work. In your service class you may work directly with your data source (in your case, the DbContext), but once again, if you find yourself writing a lot of business rules in addition to the data access, you will probably want to separate your business logic from your data access.

At that point, you will probably have a class that does nothing but the data access. Sometimes this is called a Repository, but it doesn't really matter what the name is. The point is that all of the code for getting data into and out of the database is in one place.

For every MVC project I've worked on, I've always ended up with a structure like:

Controller

public class BookController : Controller
{
    ILibraryService _libraryService;

    public BookController(ILibraryService libraryService)
    {
        _libraryService = libraryService;
    }

    public ActionResult Details(String isbn)
    {
        Book currentBook = _libraryService.RetrieveBookByISBN(isbn);
        return View(ConvertToBookViewModel(currentBook));
    }

    public ActionResult DoSomethingComplexWithBook(ComplexBookActionRequest request)
    {
        var responseViewModel = _libraryService.ProcessTheComplexStuff(request);
        return View(responseViewModel);
    }
}

Business Service

public class LibraryService : ILibraryService
{
     IBookRepository _bookRepository;
     ICustomerRepository _customerRepository;

     public LibraryService(IBookRepository bookRepository, 
                           ICustomerRepository _customerRepository )
     {
          _bookRepository = bookRepository;
          _customerRepository = customerRepository;
     }

     public Book RetrieveBookByISBN(string isbn)
     {
          return _bookRepository.GetBookByISBN(isbn);
     }

     public ComplexBookActionResult ProcessTheComplexStuff(ComplexBookActionRequest request)
     {
          // Possibly some business logic here

          Book book = _bookRepository.GetBookByISBN(request.Isbn);
          Customer customer = _customerRepository.GetCustomerById(request.CustomerId);

          // Probably more business logic here

          _libraryRepository.Save(book);

          return complexBusinessActionResult;

     } 
}

Repository

public class BookRepository : IBookRepository
{
     LibraryDBContext _db = new LibraryDBContext();

     public Book GetBookByIsbn(string isbn)
     {
         return _db.Books.Single(b => b.ISBN == isbn);
     }

     // And the rest of the data access
}

Php – how to structure MVC models and ORM models

I would not call myself a backend developer, so before I answer, I will strongly encourage you to spend some time looking at how others are doing MVC architecture. I think CakePHP is a great place to start (and their code is very well documented!).

The way I would set out about doing it is to make a /Utilities folder that other parts of your program can call on when needed. Things that you might often be using in multiple controllers, views or models. You could place standard validation rules -- notEmpty(), alphaNumeric(), email(), etc. -- in this file (/Utilites/Validation.php).

Then you might make a /Models/Model.php that has your basic model template (save, delete, update, beforeSave, etc.) that would let new models inherit from it so you don't have to copy/paste repeated lines of code everywhere. Then you could make your userModel and if necessary have custom validation inside of that file.

Again, not a back end developer but I am familiar with CakePHP and looking out how they decided to handle these difficulties might give you some ideas!

Best Answer

Related Solutions

ASP.NET MVC – Separating Data Access in ASP.NET MVC

Php – how to structure MVC models and ORM models

Related Topic