best way to project ViewModel back into Model

Question

Consider having ViewModel :

public class ViewModel
{
    public int id {get;set;}
    public int a {get;set;}
    public int b {get;set;}
}

Answer 1

For this purpose we have written a simple mapper. It maps by name and ignores virtual properties (so it works with entity framework). If you want to ignore certain properties add a PropertyCopyIgnoreAttribute.

Usage:

PropertyCopy.Copy<ViewModel, Model>(vm, dbmodel);
PropertyCopy.Copy<Model, ViewModel>(dbmodel, vm);

Code:

public static class PropertyCopy
{
    public static void Copy<TDest, TSource>(TDest destination, TSource source)
        where TSource : class
        where TDest : class
    {
        var destProperties = destination.GetType().GetProperties()
            .Where(x => !x.CustomAttributes.Any(y => y.AttributeType.Name == PropertyCopyIgnoreAttribute.Name) && x.CanRead && x.CanWrite && !x.GetGetMethod().IsVirtual);
        var sourceProperties = source.GetType().GetProperties()
            .Where(x => !x.CustomAttributes.Any(y => y.AttributeType.Name == PropertyCopyIgnoreAttribute.Name) && x.CanRead && x.CanWrite && !x.GetGetMethod().IsVirtual);
        var copyProperties = sourceProperties.Join(destProperties, x => x.Name, y => y.Name, (x, y) => x);
        foreach (var sourceProperty in copyProperties)
        {
            var prop = destProperties.FirstOrDefault(x => x.Name == sourceProperty.Name);
            prop.SetValue(destination, sourceProperty.GetValue(source));
        }
    }
}

Answer 2

Overall that might be not the answer, that you are looking for, but here's a quote from AutoMapper author:

I can’t for the life of me understand why I’d want to dump a DTO straight back in to a model object.

I believe best way to map from ViewModel to Entity is not to use AutoMapper for this. AutoMapper is a great tool to use for mapping objects without using any other classes other than static. Otherwise, code gets messier and messier with each added service, and at some point you won't be able to track what caused your field update, collection update, etc.

Specific issues often faced:

1. Need for non-static classes to do mapping for your entities

   You might need to use DbContext to load and reference entities, you might also need other classes - some tool that does image upload to your file storage, some non-static class that does hashing/salt for password, etc etc... You either have to pass it somehow to automapper, inject or create inside AutoMapper profile, and both practices are pretty troublemaking.

2. Possible need for multiple mappings over same ViewModel(Dto) -> Entity Pair

   You might need different mappings for same viewmodel-entity pair, based on if this entity is an aggregate, or not + based on if you need to reference this entity or reference and update. Overall this is solvable, but causes a lot of not-needed noise in code and is even harder to maintain.

3. Really dirty code that's hard to maintain.

   This one is about automatic mapping for primitives (strings, integers, etc) and manual mapping references, transformed values, etc. Code will look really weird for automapper, you would have to define maps for properties (or not, if you prefer implicit automapper mapping - which is also destructive when paired with ORM) AND use AfterMap, BeforeMap, Conventions, ConstructUsing, etc.. for mapping other properties, which complicates stuff even more.

4. Complex mappings

   When you have to do complex mappings, like mapping from 2+ source classes to 1 destination class, you will have to overcomplicate things even more, probably calling code like:

   var target = new Target();
   Mapper.Map(source1, target);
   Mapper.Map(source2, target);
   //etc..
   

   That code causes errors, because you cannot map source1 and source2 together, and mapping might depend on order of mapping source classes to target. And I'm not talking if you forget to do 1 mapping or if your maps have conflicting mappings over 1 property, overwriting each other.

These issues might seem small, but on several projects where I faced usage of automapping library for mapping ViewModel/Dto to Entity, it caused much more pain than if it was never used.

Here are some links for you:

• Jimmy Bogard, author of AutoMapper about 2-way mapping for your entities
• A small article with comments about problems faced when mapping ViewModel->Entity with code examples
• Similar question in SO: Best Practices For Mapping DTO to Domain Object?

Answer 3

I want to address a specific point in your question, regarding "forgetting some properties and disaster happens". The reason this happens is that you do not have a constructor on your model, you just have setters that can be set (or not) from anywhere. This is not a good approach for defensive coding.

I use constructors on all my Models like so:

    public User(Person person, string email, string username, string password, bool isActive)
    {
        Person = person;
        Email = email;
        Username = username;
        Password = password;
        IsActive = isActive;                    
    }

    public Person Person { get; }          
    public string Email { get;  }
    public string Username { get; }
    public string Password { get; }
    public bool IsActive { get; }

As you can see I have no setters, so object construction must be done via constructor. If you try to create an object without all the required parameters the compiler will complain.

With this approach it becomes clear, that tools like AutoMapper don't make sense when going from ViewModel to Model, as Model construction using this pattern is no longer about simple mapping, its about constructing your object.

Also as your Models become more sophisticated you will find that they differ significantly from your ViewModels. ViewModels tend to be flat with simple properties like string, int, bool etc. Models on the other hand often include custom objects. You will notice in my example there is a Person object, but UserViewModel would use primitives instead like so:

public class UserViewModel
{
   public int Id { get; set; }
   public string LastName { get; set; }
   public string FirstName { get; set; }
   public string Email { get; set; }
   public string Username { get; set; }
   public string Password { get; set; }
   public bool IsActive { get; set;}
}

So mapping from primitives to complex objects limits AutoMapper's usefulness.

My approach is always manual construction for the ViewModels to Model direction. In the other direction, Models to ViewModels, I often use a hybrid approach, I would manually map Person to FirstName, LastName, I'd but use a mapper for simple properties.

Edit: Based on the discussion below, AutoMapper is better at unflattering than I believed. Though I will refrain from recommending it one way or the other, if you do use it take advantage of features like Construction and Configuration Validation to help prevent silent failures.