Home > front end >  ViewModel and Model mapping (ASP.NET, Entity Framework)
ViewModel and Model mapping (ASP.NET, Entity Framework)

Time:04-24

I have the following model:

public class Reference
    {

        public string Firstname { get; set; }

        public string Lastname { get; set; }

        public string Title { get; set; }

        public string Company { get; set; }

        public string PhoneNumber { get; set; }

    }

And the following ViewModel:

public class ViewModel
    {
        ...

        public List<Reference> References { get; set; }
      
        public List<...> ... { get; set; } //// etc.

        ...
    }
}

I receive ViewModel from my [HttpPost] method after submitting a form:

        [HttpPost]
        [Authorize]
        [ValidateAntiForgeryToken]
        public IActionResult Create(ViewModel model)
        {
           ...
        }

My question is why should I use automapper if I can just type the following in order to map my ViewModel properties to the Reference object whenever I want to insert the object Reference to the database?

         for (int i = 0; i < model.References.Count; i  )
            {
                Reference reference = model.References[i];
                db.References.Add(reference);
            }

I also see many people take the following approach below. They map each property one by one. What is the reason for this whenever we can just type Reference reference = model.References[i]; ?

         for (int i = 0; i < model.References.Count; i  )
            {
                var reference = new Reference
                {
                  Firstname = model.References[i].Firstname,
                  Lastname = model.References[i].Lastname,
                  Title = model.References[i].Title,
                  Company = model.References[i].Company,
                  Phonenumber = model.References[i].Phonenumber,
                }
            }

What is the best practice that I should follow? Right know I just map all ViewModel properties at once to my object and it is working perfectly. Why then people use to map properties one by one or use Automapper?

         for (int i = 0; i < model.References.Count; i  )
            {
                Reference reference = model.References[i];
                db.References.Add(reference);
            }

CodePudding user response:

You create a new memory area in

var reference = new Reference
                {
                  Firstname = model.References[i].Firstname,
                  Lastname = model.References[i].Lastname,
                  Title = model.References[i].Title,
                  Company = model.References[i].Company,
                  Phonenumber = model.References[i].Phonenumber,
                }

You can modify it without making changes model.References[i].

You use the same memory area in

Reference reference = model.References[i];

If you modify reference, you change model.References[i] too.

That is difference thing.

If you don't need to do any thing after, just use

db.References.Add(model.References[i]);

CodePudding user response:

Each layer of your code should be independent and only communicate with the one below it. E.g. your Presentation/API should only communicate with your business layer, and your business layer should only communicate with your data layer. Entities from your data layer should not be used by the API layer. This is good practice for separation of concerns. In your case, your Reference class may have properties that you don't want to expose in one endpoint in your API, but you DO want to expose in another.

You may find (initially) that your view model contains exactly the same properties as your business layer. That is to be expected, but as the project grows, this may change. This one-to-one mapping is exactly what AutoMapper is designed for.

Continuing down the path you are suggesting, means you may end up in the situation I was in on a project about 5 years ago, where a database entity was being used as a ViewModel, and the password hash and salt were being sent to the UI. I'm sure you can agree this is bad.

  • Related