asp.mvc model design

Question

I am pretty new to MVC and I am looking for a way to design my models.

I have the MVC web site project and another class library that takes care of data access and constructing the business objects.

If I have in that assembly a class named Project that is a business object and I need to display all projects in a view ... should I make another model class Project? In this case the classes will be identical. Do I gain something from doing a new model class? I don't like having in views references to objects from another dll ... but i don't like duplicating the code neither.

Did you encounter the same problem?

Answer 1

I usually use a combination of existing and custom classes for models, depending on how closely the views map to the actual classes in the datastore. For pure crud pages, using the data class as the model is perfect. In real world use though you usually end up needing a few other bits of data. I find the easiest way to combine them is something like

// the class from the data store
public class MyDataObject {
    public string Property1 {get;set;}
    public string Property2 {get;set;}
    }

// model class in the MVC Models folder
public class MyDataObjectModel {
    public MyDataObject MyDataObject {get;set;}
    // list of values to populate a dropdown for Property2
    public List<string> Property2Values {get;set;}
    // related value fetched from a different data store
    public string Property3 {get;set;}
    }

I also have quite a few model classes that are just a set of form fields - basically corresponding to action parameters from a particular form rather than anything that actually ends up in the database.

Answer 2

If it is exactly the same project then obviously don't need to duplicate the Project class, just use it as is in the view. But in real life often views have specific requirements and it it a good practice to define view model classes in your MVC application. The controller will then map between the model class and the view model to be passed to the view.

Answer 3

You will likely find differing opinions on this. I will give you mine:

I tend to, by default, reuse the object. If the needs of the view change and it no longer needs most/all of the data in the business object, then I'll create a separate view. I would never change the business object to suit the view itself.

If you need most/all of the information in the business object, and need additional data, then I would create a view that holds a reference to the business object and also has properties for the additional data points you need.

One benefit of reusing the business object is that, depending on the data access technology you are using, you can get reuse out of validation. For isntance, ASP.NET MVC 3 coupled with Entity Framework is nice as they both use the attributes in the System.ComponentModel namespace for validation.

Answer 4

That depends on what you mean by model. In the architecture I typically use, I have my Domain model, which is a collection of classes in a separate class library. I use DataAnnotations and built in validation to automatically validate my model when saving.

Then there is the View model, which I place in my MVC project. View models only have the information relevant to the view. I use data annotations here as well since MVC will automatically use them for my validation.

The reason for splitting the model this way is that you don't always use every piece of your domain model in a view. That means you either have to rebuild the data on the backend or you have to stash it in hidden fields. Neither is something I like,.