1

I got the following entity and VM:

public class Student
{
    public int ID {get;set;}
    public string FirstName {get;set;}  
    ...
}


public class StudentVM
{
    public int ID {get;set;}
    public string FirstName {get;set;} 
    ..
}  

Now, which of the following is a better way to convert one to another (assuming I only change the VM, which looks like the right way to do it):
This one:

public static implicit operator StudentVM(Student entity)  
    {  
        return new StudentVM  
        {  
            ID=entity.ID,
            FirstName=entity.FirstName
            ...
        };
    }  

..Or that one:

public StudentVM(Student entity)
    {
        ID=entity.ID;
        FirstName=entity.FirstName;
        ...
    }  

My personal opinion is that you can't say an entity "equals" a VM or vise versa, so I would go with the second way, but I couldn't find a sufficiently concise argument for that (or against)..

1

I'd go with extension methods or a constructor and a ToEntity() method on the VM for mapping between VMs and Entities.

You're right to only change the VM since the entities should not care about their view models.

The reasoning is that the VM should be tailored for the View specifically, so it may lay out data differently. Your Student may have a reference to a List of full blown Class objects, but your VM might just need a list of Id-Name pairs to fill up a drop down. It might need other data that is not directly related to the Student, and it might "denormalize" some other data to make working with it in the UI easier. You might need to provide several other entities to a VM to create an object your view can consume easily.

Operator overloading seems a bit awkward for this purpose.

  • I think the op meant "Conversion Operators" and not "Operator Overloading" (used for overloading operators like +, -, !, == etc), so if you were referring to operator overloading then, yes, that would be awkward, but in my opinion, using conversion operators is just fine, allowing you to define conversion methods on view models to convert them to and from entities. – ashilon Mar 30 '18 at 12:21
  • I did not know about conversion operators, I just looked them up. Can you provide additional data like lookup lists or something similar that the VM might need? It looks like that any data that's not already in the entity would need to be provided later via properties. I'd still prefer a constructor with it's explicit dependencies. – Ivan Pintar Apr 1 '18 at 15:55
0

I actually started out using constructors to initialize the view models. It worked OK, until the hierarchy of the view model got large, and a change 3 or 4 levels deep necessitated a new argument to the top level view model, which is passed down to the deepest layer.

I found using constructors to map entities to view models works in many cases, but is troublesome to maintain for the root view model of an entire page.

There is a design pattern that specifically addresses the creation of new objects: the Factory Pattern.

I ended up with a compromise between a view model factory and constructors on other view models that didn't represent an entire page.

Basically, if the view model was used to render a partial I've been able to utilize constructors with fewer maintenance headaches.

Mapping Back to Entities

You should erase the phrase "mapping view models back to entities" and instead focus on the use case.

A use case could be creating a new student or updating an existing student. You need additional classes and/or methods that focus on the use cases that modify information in the system. It's not a "mapping" thing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.