EF生成的类和模型之间的关系？

Question

I'm using ASP .NET MVC (C#) and EntityFramework (database first) for a project.

Let's say I'm on a "Movie detail" page which shows the detail of one movie of my database. I can click on each movie and edit each one. Therefore, I have a Movie class, and a Database.Movie class generated with EF.

My index action looks like :

    public ActionResult MovieDetail(int id)
    {
        Movie movie = Movie.GetInstance(id);
        return View("MovieDetail", movie);    
    }

GetInstance method is supposed to return an instance of Movie class which looks like this for the moment :

    public static Movie GetInstance(int dbId)
    {
        using (var db = new MoviesEntities())
        {
            Database.Movie dbObject = db.Movies.SingleOrDefault(r => r.Id == dbId);
            if (dbObject != null)
            {
                Movie m = new Movie(dbObject.Id, dbObject.Name, dbObject.Description);
                return m;
            }
            return null;
        }
    }

It works fine but is this a good way to implement it? Is there an other cleaner way to get my instance of Movie class ? Thanks

Answer 1

is this a good way to implement it?

That's a very subjective question. It's valid, and there's nothing technically wrong with this implementation. For my small-size home projects, I've used similar things.

But for business applications, it's better to keep your entities unrelated to your MVC application. This means that your data context + EF + generated entities should be kept in a separate project (let's call it the 'Data' project), and the actual data is passed in the form of a DTO.

So if your entity resembles this:

public class Person {
       public int Id { get; set; }
       public string Name { get; set; }
}

You'd expect there to be an equivalent DTO class that is able to pass that data:

public class PersonDTO {
       public int Id { get; set; }
       public string Name { get; set; }
}

This means that your 'Data' project only replies with DTO classes, not entities .

public static MovieDTO GetInstance(int dbId)
{
    ...
}

It makes the most sense that your DTOs are also in a separate project. The reason for all this abstraction is that when you have to change your datacontext (eg the application will start using a different data source), you only need to make sure that the new data project also communicates with the same DTOs. How it works internally, and which entities it uses, is only relevant inside the project. From the outside (eg from your MVC application), it doesn't matter how you get the data, only that you pass it in a form that your MVC projects already understand (the DTO classes).

All your MVC controller logic will not have to change, because the DTO objects haven't changed. This could save you hours. If you link the entity to your Controller AND View, you'll have to rewrite both if you suddenly decide to change the entity.

If you're worried about the amount of code you'll have to write for converting entities to DTOs and vice versa, you can look into tools like Automapper .

The main question: Is this needed?

That, again, is a very subjective question. It's relative to the scope of the project, but also the expected lifetime of the application. If it's supposed to be used for a long time, it might be worth it to keep everything interchangeable. If this is a small scale, short lifetime project, the added time to implement this might not be worth it.

I can't give you a definitive answer on this. Evaluate how well you want the application to adapt to changes, but also how likely it is that the applicaiton will change in the future.

Disclaimer: This is how we do it at the company where I work. This is not the only solution to this type of problem, but it's the one I'm familiar with. Personally, I don't like making abstractions unless there's a functional reason for it.

Answer 2

A few things:

1. The naming you're using is a little awkward and confusing. Generally, you don't ever want to have two classes in your project named the same, even if they're in different namespaces. There's nothing technically wrong with it, but it creates confusion. Which Movie do I need here? And if I'm dealing with a Movie instance, is it Movie or Database.Movie ? If you stick to names like Movie and MovieDTO or Movie and MovieViewModel , the class names clearly indicate the purpose (lack of suffix indicates a database-backed entity).

2. Especially if you're coming from another MVC framework like Rails or Django, ASP.NET's particular flavor of MVC can be a little disorienting. Most other MVC frameworks have a true Model, a single class that functions as the container for all the business logic and also acts as a repository (which could be considered business logic, in a sense). ASP.NET MVC doesn't work that way. Your entities (classes that represent database tables) are and should be dumb. They're just a place for Entity Framework to stuff data it pulls from the database. Your Model (the M in MVC) is really more a combination of your view models and your service/DAL layer. Your Movie class (not to be confused with Database.Movie ... see why that naming bit is important) on the other hand is trying to do triple duty, acting as the entity, view model and repository. That's simply too much. Your classes should do one thing and do it well.

3. Again, if you have a class that's going to act as a service or repository, it should be an actual service or repository, with everything those patterns imply. Even then, you should not instantiate your context in a method. The easiest correct way to handle it is to simply have your context be a class instance variable. Something like:

    public class MovieRepository { private readonly MovieEntities context; public MovieRepository() { this.context = new MovieEntities(); } } 

   Even better, though is to use inversion of control and pass in the context:

    public class MovieRepository { private readonly MovieEntities context; public MovieRepository(MovieEntities context) { this.context = context; } } 

   Then, you can employ a dependency injection framework, like Ninject or Unity to satisfy the dependency for you (preferably with a request-scoped object) whenever you need an instance of MovieRepository . That's a bit high-level if you're just starting out, though, so it's understandable if you hold off on going the whole mile for now. However, you should still design your classes with this in mind. The point of inversion of control is to abstract dependencies (things like the context for a class that needs to pull entities from the database), so that you can switch out these dependencies if the need should arise (say perhaps if there comes a time when you're going to retrieve the entities from an Web API instead of through Entity Framework, or even if you just decide to switch to a different ORM, such as NHibernate). In your code's current iteration, you would have to touch every method (and make changes to your class in general, violating open-closed).

Answer 3

entity-model never should act as view-model. Offering data to the views is an essential role of the view-model. view-model can easily be recognized because it doesn't have any other role or responsibility other than holding data and business rules that act solely upon that data. It thus has all the advantages of any other pure model such as unit-testability.

A good explanation of this can be found in Dino Esposito's The Three Models of ASP.NET MVC Apps.

Answer 4

You can use AutoMapper

What is AutoMapper?

AutoMapper is a simple little library built to solve a deceptively complex problem - getting rid of code that mapped one object to another. This type of code is rather dreary and boring to write, so why not invent a tool to do it for us?

How do I get started?

Check out the getting started guide .

Where can I get it?

First, install NuGet. Then, install AutoMapper from the package manager console:

PM> Install-Package AutoMapper