Model design advice for ASP.NET MVC

Question

I'm currently in the process of converting some small personal web sites from WebForms to MVC. With the existing sites, the database schema is solid but I had never really taken the time to build proper data/business models/layers. The aspx pages all talked to the database directly using a variety of Views and Stored Procedures that were created as needed for convenience. With MVC, I'm now trying to "do it right" as they say and use things like LINQ to SQL and/or the Entity Framework to build a proper data model or models for the application.

My question revolves around what goals I should have for building data models. I've read various pattern related articles and I realize that ultimately the answer is likely going to depend on the characteristics of my data. But generally should I attempt to build bigger models that encompass as much of the database as possible so that there's only one way to interact with a given set of tables? Or should I build smaller custom models for each MVC View that only contain the data and access that View will need?

Answer 1

I would go for the model representing the actual data logic within your current system and have your controllers return the piece of the model which the view needs such as:

Controller:

public ActionResult index()
{
    var ListOfObjects = DataHelper.GetAll();
    ViewData.Add(ListOfObjects);
    return View();
}

public ActionResult ViewObject(int id)
{
    var Object= DataHelper.GetObject();
    ViewData.Add(Object);
    return View();
}

public ActionResult ViewObjectChild(int Objectid, int ChildId)
{
    var Child= DataHelper.GetChildObject(Objectid, ChildId);
    ViewData.Add(Child);
    return View();
}

On the view

/

<%  var myListOfObjects = ViewData.Get<IList<Object>>(); %>

/ViewObject/1/

<%  var myobject= ViewData.Get<Object>(); %>

/ViewChild/1/1/

<%  var myChild = ViewData.Get<Child>(); %>

Note I have used MVC Contrib typed functions I highly recommend these.

Answer 2

Or should I build smaller custom models for each MVC View that only contain the data and access that View will need?

This would probably be better.

Do not forget, you can stick your models in hierarchies, so common properties, like ids, names, preferences can be present in each model.

Fat expanded models could be better for enterprise application, where framework automatically does lot of stuff based on preloaded user preferences, user roles, access rights etc. For a small personal project would probably be better to try to keep your models small and clean. It is also a protection. By not putting unnecessary data into a model you ensure your view will not by mistake display wrong entries or submitting a form would not by mistake overwrite some other data.

Answer 3

Generally, you would have one comprehensive domain model for the database. You can use (modify/add/remove/etc.) the domain model in your service layer or the controller if it is a small app.

However, for your views, you can use presentation objects to make the views easier to maintain. These are sometimes also called DTO or view model objects. Basically what you do is create an object that contains all the data from the model that is necessary for the view to be populated.

For example:

Your model may include:

public class Car() 
{
  public string Model;
}

public class Driver()
{
  public string Name;
}

You want the view to output the name and model of the car and you would have to pass both the Car and Driver model objects the view.

Rather than sending the two model objects directly from the controller to the view, you can create an object which contains just the data you need:

public class CarAndDriverViewModel()
{
  public string CarMake;
  public string DriverName;
}

You would populate this object from the domain data and pass that to the view. And the view would be:

model.DriverName + ": " + model.CarMake

Now you don't have to worry about lazy loading issues or complicated view logic to deal with model peculiarities. It's more work to create these view model objects but they really help keep the view clean and provides an easy way to do formatting before sending data to the view.

There are projects and conventions you can use to help automate the creation of the view models, if you want to look into them. AutoMapper is an example.