ASP.NET MVC – Should an Application Directly Use Entity Framework as the Model?

asp.netasp.net-mvccentity-framework

I'm building my first MVC application in Visual Studio 2013 (MVC 5) and I'm a bit unclear on the best way to setup my model.

I've generated an entity framework model using code-first from an existing database. My first instinct was to create some intermediary classes that would be the model used by the views and have those classes work with the entity framework classes.

As I was writing the intermediary classes I realized that I was mostly just re-implementing a lot of the things that the EF classes already did just with the occasional private setter or cast from one datatype to another. So that seemed like a waste.

Is the general rule to directly use the entity framework classes as the Model for an MVC application? Or is there some benefit I'm missing for building these intermediary classes?

Best Answer

In my applications I have always separated things out, with different models for the database (Entity Framework) and MVC. I have separated these out into different projects too:

Example.Entities - contains my entities for EF and the DB context for accessing them.
Example.Models - contains MVC models.
Example.Web - web application. Depends on both Example.Domain and Example.Models.

Instead of holding references to other objects like the domain entities do, the MVC models hold IDs as integers.

When a GET request for a page comes in, the MVC controller performs the database query, which returns an entity. I have written "Converter" methods that take a domain entity and convert it to an MVC model. There are other methods that do the opposite (from an MVC model to a domain entity). The model then gets passed to the view, and thus to the client.

When a POST request comes in, the MVC controller gets an MVC model. A converter method converts this to a domain entity. This method also performs any validations that can't be expressed as attributes, and makes sure that if the domain entity already exists that we are updating it rather than getting a new one. The methods usually look something like this:

public class PersonConverter
{
    public MyDatabaseContext _db;

    public PersonEntity Convert(PersonModel source)
    {
         PersonEntity destination = _db.People.Find(source.ID);

         if(destination == null)
             destination = new PersonEntity();

         destination.Name = source.Name;
         destination.Organisation = _db.Organisations.Find(source.OrganisationID);
         //etc

         return destination;
    }

    public PersonModel Convert(PersonEntity source)
    {
         PersonModel destination = new PersonModel()
         {
             Name = source.Name,
             OrganisationID = source.Organisation.ID,
             //etc
         };

         return destination;
    }
}

By using these methods I take the duplication out that would otherwise occur in each controller. The use of generics can deduplicate things even further.

Doing things this way provides multiple benefits:

You can customise a model to a specific view or action. Say you have a signup form for a person that when submitted, creates many different entities (person, organisation, address). Without seperate MVC models this will be very difficult.
If I need to pass more information to the view than would otherwise be available just in the entity, or combine two entities into a single model, then my precious database models are never touched.
If you ever serialise an MVC model as JSON or XML, you only get the immediate model being serialised, not every other entity linked to this one.

Related Solutions

ASP.NET MVC – Should MVC’s M, V, and C Be Aware of Domain Entities?

I haven't worked much with MVC, however I have worked a lot with MVVM and here's my take on it:

Question, Answer, and User are all data objects. Its OK for them to know of each other, but they should not be aware of anything outside of the data object layer, such as Views, Controllers, ViewModels, etc.

In an ideal world, your View only references the Models. They might know of the Controller, but they shouldn't have to reference it directly. The ViewModel only knows of other Models. The Controller knows about Models and ViewModels. It doesn't care about the View at all, even though it supplies the View with ViewModels or Models.

So your objects end up looking like this:

M odels come in two varieties: Models and ViewModels.
- Models are simple data objects that simply exist to hold data, and are generally a reflection of database data. They do not access the database or contain any sort of business logic that is unrelated to them.
- ViewModels are data objects that contain data that the View needs, not necessarily what the database needs. They can contain Models, although Models should not contain ViewModels.
C ontrollers contain your business logic. They control the data access calls, creating Models/ViewModels to pass to the View, advanced business logic such as permissions, etc. They basically control the entire code layer.
V iews are just used to give the users a user-friendly interface. They accept either a ViewModel or Model, and display it in some way that looks nice to the user.

Entity Framework in MVVM WPF – Best Way to Wire Up Database Context

I've looked into this quite a bit and haven't found a "perfect" solution. The repository pattern works wonderfully for MVC applications where the context is short lived because it exists in a short lived controller, but the problem happens when you try to apply that same structure to a wpf app where the VM can persist for long periods of time.

I have used this solution in the past which is much more simple than many of the repo patterns I have seen that attempt to abstract things out to an extreme amount, resulting in near unreadable amounts of code that are difficult to debug. Here are the steps...

Create a separate project for the EDMX to act as your Data access layer
Create a "Repositories" folder under the same project
Create a base class "BaseRepository" to act as the "Unit of Work". IDisposable will allow you to use this in a using(){} and the partial will allow you do implement other repositories
```
public partial class MyEntityRepository : IDisposable
{
    MyEntities context = new MyEntities();

    public void Dispose()
    {
        context.Dispose();
    }
}
```

Create another file called "MyOtherRepository". create the same partial class but implement methods based on what you want that file to contain

public partial class MyEntityRepository
{
    public void MyOtherMethodSave(EntityObject obj)
    {
        //work with context
        ...

        context.SaveChanges();
    }
}

Now in your VM you can do this...

using(MyEntityRepository repo = new MyEntityRepository())
{
     repo.MyOtherMethodSave(objectToSave);
}

This groups all your repositories under one class so you don't have to deal with separate context. It allows you better manage different repos by grouping the methods into different files and helps prevent code duplication. On top of that, your contexts are as short lived as they were without using this pattern.

The disadvantage is that with larger systems, you may have a lot of methods that get bundled under your repo. One solution in that case would be to implement some basic common commands like "Find" or "Add", and implement specialized ones in their respective repository.

Best Answer

Related Solutions

ASP.NET MVC – Should MVC’s M, V, and C Be Aware of Domain Entities?

Entity Framework in MVVM WPF – Best Way to Wire Up Database Context

Related Topic