I'm debating with myself whats the point in creating ViewModel classes in a project which uses Entity Framework?
I currently have a project which uses EntityFramework. My solution is structured basically like this:
- UI project (contains controllers and Views)
- Model project (contains EntityFramework model)
- Services project (contains service classes which talk to Model Project to serve up the entities out of the model project to the UI project)
My controllers pass the entities that Entity Framework creates straight to the view.
It's nice and simple.
In the past I would of created separate view model classes and mapped from the entities that EntityFramework creates to these view models. But now I'm struggling to see the point.
I'm currently helping out on a project which map from the entities produced by entity framework to view models. It actually uses AutoMapper to do this.
Now this all seems like a lot of effort and code for very little gain.
Am I missing something here?
I can think of a couple of cases when a separate layer of view model classes is a good way to go, and I'll try to explain them in terms of a general ORM tool and a general MVC framework - note that neither of these two cases are specific to ASP.NET MVC Framework with Entity Framework (nor even to programming in .NET...).
Also: please note that in the following few paragraphs I'm only referring to view models specifically. I'll adress problems like mass assignment vulnerabilities at the end of this post.
Reason 1: Give the View layer exactly the data it needs, and nothing else
This is a somewhat "purist" goal - in a true MVC application, the view layer only has access to data that it needs at the moment, and nothing else. The view model object now becomes a specification from the view layer to the controller: "This is the data I need to show the view you requested." In order to adhere to fundamental MVC principles, you want to make sure that all decisions on what data to display are made by the controller.
In other words, if you want to display a user's first and last name, username and picture, you don't need (or want) to give the view layer an object which also has information about the user's password, roles (or, to take some properties that might not be so sensitive, height or middle names). Instead, you give the view an object with properties for first name, last name, username and picture, and the view decides only how to present the data. That way, you're sure that the decision on what data is presented stays in the controller layer.
Reason 2: Avoid problems with your ORM tool's tracking abilities
Some ORM tools - even some of those that return regular objects1 - use quite sophisticated methods to keep track of changes in the objects you get from the data layer, in order to make changing the records easier. For instance, you might get an object from your data store, change some properties on that instance and then call a save() method somewhere else, and the object is updated in the database. Depending on the ORM tool, forwarding your ORM-entities to the view layer can have any range of consequenses, from performance issues (worst case: database connections kept open) to unwanted effects (say, a bug in the view layer changes properties in the data store). To avoid those, re-map your entities to "true regular objects", that have no relation to your ORM tool, before sending them too far down the application pipeline. View models is one way (of many) to achieve this goal.
Note that whether this is necessary or not is entirely dependent on your ORM tool. I don't know the inner workings of Entity Framework nearly well enough to know if you have to care - but in (very) early incarnations of EF this was a problem, at least when not using the Code-First approach.
Conclusions: do you have to care?
No, not necessarily. You could be doing just fine without view models, and in that case they're just another layer of abstraction which doesn't really add anything but complexity to your application. It all boils down to wheter your ORM tool puts any requirements on your code, and whether you're an "MVC purist".
Side note: But what about mass assignment vulnerabilities?
Queti-Mporta already pointed out that mass assignment vulnerabilities could be a problem. I agree that this is a serious concern, but I don't agree that it is solved by using view models.
To me, a view model is a data transfer object from the controller to the view, helping the controller to sort out and summarize the data that should be displayed. To avoid problems like mass assignment vulnerabilities, I usually use edit models, which are very similar to view models but in the other direction - i.e. to the controller. Not everyone makes this distinction - and I don't care very much if you do or not. But using this vocabulary, I'd recommend always using edit models when you let users alter your data, and using view models only when it helps you.
1 In .NET usually referred to as "POCO's", or Plain Old CLR Objects. Java has its equivalence in POJO's (Plain Old Java Objects) and if you can think of a language that can be used in object oriented programming, that language also has an equivalence.
I personally like using ViewModels because they can contain information that is specific to a view. But mainly, as a way to prevent exposing my Entities directly on the view.
A side benefit is to avoid mass assignment vulnerabilities. These also exist in Ruby.
I would take a look at this question What is ViewModel in MVC which explains the purpose of the ViewModel.
There is nothing wrong with passing the Model directly from your Entity into the View, but a ViewModel can be used when your Model is not an exact match for the data you need.
来源：https://stackoverflow.com/questions/15391322/viewmodels-with-asp-net-mvc-4-and-entityframework-whats-the-point