Models, ViewModels, DTOs in MVC 3 application Models, ViewModels, DTOs in MVC 3 application asp.net asp.net

Models, ViewModels, DTOs in MVC 3 application


I would solve your problem by using an auto-mapping tool (like AutoMapper) to do the mapping for you. In cases where the mapping is easy (for example if all properties from one class should be mapped to properties with the same name on another class) AutoMapper will be able to do all the hook-up work for you, and you'll have to give a couple of lines of code to note that there should be a map between the two at all.

That way, you can have your entities in Domain, and a couple of view model classes in your WebUI, and somewhere (preferrably in WebUI or a sub namespace of the same) define maps between them. Your view models will in effect be DTOs, but you won't have to worry much about the conversion process between the domain and your DTO classes.

Note: I would strongly recommend against giving your Domain entities straight to the views of your MVC web UI. You don't want EF to "stick around" all the way to the front-end layer, in case you later want to use something other than EF.


introduce ViewModels which live in the WebUI project and expose IQueryables and the EF data context from the service to the WebUI project. Then I could directly project into those ViewModels.

The trouble with this is you soon run into problems using EF trying to 'flatten' models. I encountered something similar when I had a CommentViewModel class that looked like this:

public class CommentViewModel{    public string Content { get; set; }    public string DateCreated { get; set; }}

The following EF4 query projection to the CommentViewModel wouldn't work as the couldn't translate the ToString() method into SQL:

var comments = from c in DbSet where c.PostId == postId                select new CommentViewModel()                {                    Content = c.Content,                   DateCreated = c.DateCreated.ToShortTimeString()                };

Using something like Automapper is a good choice, especially if you have a lot of conversions to make. However, you can also create your own converters that basically convert your domain model to your view model. In my case I created my own extension methods to convert my Comment domain model to my CommentViewModel like this:

public static class ViewModelConverters{    public static CommentViewModel ToCommentViewModel(this Comment comment)    {        return new CommentViewModel()         {             Content = comment.Content,            DateCreated = comment.DateCreated.ToShortDateString()         };    }    public static IEnumerable<CommentViewModel> ToCommentViewModelList(this IEnumerable<Comment> comments)    {        List<CommentViewModel> commentModels = new List<CommentViewModel>(comments.Count());        foreach (var c in comments)        {            commentModels.Add(c.ToCommentViewModel());        }        return commentModels;    }}

Basically what I do is perform a standard EF query to bring back a domain model and then use the extension methods to convert the results to a view model. For example, the following methods illustrate the usage:

public Comment GetComment(int commentId){    return CommentRepository.GetById(commentId);}public CommentViewModel GetCommentViewModel(int commentId){    return CommentRepository.GetById(commentId).ToCommentViewModel();}public IEnumerable<Comment> GetCommentsForPost(int postId){    return CommentRepository.GetCommentsForPost(postId);}public IEnumerable<CommentViewModel> GetCommentViewModelsForPost(int postId){    return CommentRepository.GetCommentsForPost(postId).ToCommentViewModelList();}


Talking about Models, ViewModels and DTOs is confusing, personally I don't like to use these terms. I prefer to talk about Domain Entities, Domain Services, Operation Input/Result (aka DTOs). All of these types live in the Domain layer. Operations is the behavior of Entities and Services. Unless you are building a pure CRUD application the presentation layer only deals with Input/Result types, not Entities. You don't need additional ViewModel types, these are the ViewModels (in other words, the Model of the View). The View is there to translate the Operation Results to HTML, but the same Result could be serialized as XML or JSON. What you use as ViewModel is part of the domain, not the presentation layer.