MVC Repository - Domain Model vs Entity Model

Question

I have created a repository that is returning data from my database using Entity Framework and I need to provide this data to my view, but before I do that I need to convert those objects into my domain model.

My schema looks like this:

TABLE Project
    Id INT PRIMARY KEY
    Name NVARCHAR(100)

TABLE Resource
    Id INT PRIMARY KEY
    FirstName NVARCHAR(100)
    LastName NVARCHAR(100)

TABLE ProjectResources
    Project_Id INT PRIMARY KEY   -- links to the Project table
    Resource_Id INT PRIMARY KEY  -- links to the Resource table

I generated an entity model which ended up looking like this:

Project
|
---->ProjectResources
     |
     ---->Resource

I have a repository that returns a Project:

public interface IProjectRepository
{
    Project GetProject(int id);
}

And a controller action:

public ActionResult Edit(int id)
{
    Project project = projectRepository.GetProject(id);

    return View(project);
}

This doesn't seem to work very well when I try and POST this data. I was getting an EntityCollection already initialized error when it was trying to reconstruct the ProjectResources collection.

I think it is smarter to create a domain model that is a little simpler:

public class ProjectEdit
{
    public string ProjectName { get; set; }
    public List<ProjectResource> Resources { get; set; }
}

public class ProjectResource
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

This seems to be a little nicer since I also don't have the intermediate ProjectResources -> Resource jump. The ProjectResource would have the fields I need. Instead of doing something like:

@foreach( var resource in Model.ProjectResources ) {
    @Html.DisplayFor(m => m.Resource.FirstName)
}

I can do:

@foreach( var resoure in Model.Resources ) {
    @Html.DisplayFor(m => resource.FirstName);
}

My question is as follows Should I be returning my domain model from my repository or should that be handled by the controller or some other class in the middle? If it's handled in the controller by something that maps my Project to a ProjectEdit, what would that look like?

Answer 1

My own view is that you shouldn't return anything to your controller or a view that is dependant on the implementation of your repository.

If you're using EF with the POCO Generator, it's reasonable to use those classes for your domain model because they're independent of the EF implementation (you could replace EF and retain the POCO's).

But if you're using EF with its EntityObjects, I believe you should convert to your domain model. If your Data Access was encapsulated in a WCF service which used a repository pattern internally, I wouldn't worry so much about returning EntityObjects from the Repository. But if you're using a Repository directly from MVC, use the Domain Model as the interface to the Repository.

Answer 2

We tend to always use a ViewModel as "the class in the middle" and map to and from the actual Model using...

Automapper

...or...

ValueInjecter

Your ViewModel can then be fairly independent of your Model in terms of structure if you want it to be.