C# – Should AutoMapper be used to Map from ViewModel back into Model

.net corecentity-framework

Should AutoMapper be used to take data from ViewModel and save back into a database model?

I know the opposite practice is good software practice: to have Automapper to extract database models, and place them in Viewmodels for front end web applications.

I was reading this general article here:
The article was not specifically about Automapper, but want to validate if the opinion is true.
https://stackoverflow.com/questions/35959968/best-way-to-project-viewmodel-back-into-model

"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."

Best Answer

AutoMapper is simply a tool to facilitate mapping between objects; whether it should be used for mapping a ViewModel into an object used by the lower layers is not something that should be decided based on anything but whether it's useful in that specific mapping.

If you're handling an action where the ViewModel is very similar to the object you want to map to, such as this case:

    public class UserVM
    {
        public string Username { get; set; }
    }

    public class User
    {
        public string Username { get; set; }
    }

then yes, AutoMapper can be used without issues.

On the other hand, if the mapping requires logic, such as in this case:

    public class UserVM
    {
        public string Username { get; set; }
        public string Password { get; set; }
    }

    public class User
    {
        public string Username { get; set; }
        public string HashedPassword { get; set; }
        public string Salt { get; set; }

    }

I do not think you should use AutoMapper, but a separate service to handle the conversion.

As always, the answer is, I believe, it depends: you should first design your models without any concern or consideration towards AutoMapper or any other mapping tools, and then decide what's the best tool to accomplish what you need.

Related Solutions

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.

ASP.NET MVC – Role of ViewModels in MVC and 3-Tier Architecture

main MVC project, where M of MVC was moved to Data Access Layer

Common misconception. The M of MVC has nothing to do with data, despite the many examples and tutorials that claim so.

M is your ViewModel and should reside in your MVC project. The ViewModels you have in your BLL are actually to be named DataContracts or BusinessModels.

In your controller you have something comparable to this:

Get(id):
    dataContract = _service.Get(id);
    viewModel = Map(dataContract);
    return viewModel

In your service, something like this:

Get(id):
    dataModel = _dataAccess.Get(id);
    dataContract = Map(dataModel);
    return dataContract;

And in the DataAccess, you perform the proper joins according to the object requested. You are however of course free to add custom methods to your DataAccess when required, so your service can call those methods:

GetWithBars():
    dataModels = _repository.Query("select from foos join bars");
    return dataModels;

Best Answer

Related Solutions

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

ASP.NET MVC – Role of ViewModels in MVC and 3-Tier Architecture

Related Topic