CODEWITHSUNDEEP
asp.net-mvcmodel-view-controllerautomapperobject-object-mapping
fbarikzehy
fbarikzehy

Reputation: 5405

Is it good practice to use object-object mappers, and, if so, where to use it?

I've googled some around the internet and found some articles about the subject, but none of them satisfied me. I want to know is it good to use object-object mapper to map objects to each other? I know it depends on situation to use, but how will I realize a good or best situation to use?

Upvotes: 3

Views: 880

Answers (2)

C Bauer
C Bauer

Reputation: 5103

In addition to @Brad Christie's answer, automapping types which have minor differences into a single overarching type is generally easier if you are meaning to display them on your view alongside other products that are generated different ways.

If you'll allow me to crib off one my own previous answers, here's an example:

class SingleProduct {
    string Name {get;set;}
    decimal Price {get;set;}
    decimal GetActualPrice() { return Price; }
}
class ComboSaleProduct {
    string Name {get;set;}
    List<SingleProduct> ComboProducts {get;set;}
    decimal GetActualPrice() { return ComboProducts.Sum(p => p.GetActualPrice()); }
}

class ProductViewModel {
    string Name {get;set;}
    decimal ActualPrice {get;set;}
}

Automapper wires everything together so that you can return either of these and it will automatically map the "GetActualPrice" to ActualPrice on your viewmodel.

Upvotes: 1

Brad Christie
Brad Christie

Reputation: 101614

Taking a step back, it's best practice to separate data transfer objects (DTOs) and view models (VMs) from business objects (entities and alike). Mapping libraries, in that regard, are a means to an end and simply make that association easier.

As far as when, that's up to you. If you feel like you can convert between your business models and DTO/VMs in a way that's easy to maintain, go ahead. From my personal experience, that only goes so far (especially as the requirements change). Therefore, I'm fond of mapping libraries (specifically AutoMapper as I've come to know it's API and am comfortable plugging it in).

Having said that, any time I have to go between these two models I use AutoMapper. I simply configure it once and I'm off and running. Additional tweaks to the models (on either side) then become easier as I can change those bindings in one place (map definition file) and methods automatically "catch up".

Example:

My database contains a Record for a product:

class Product
{
    public int Id { get; set; }

    public string Description { get; set; }
    public string Name { get; set; }
    public double Price { get; set; }
    public int QuantityOnHand { get; set; }
    public int? ReorderQuantity { get; set; }
    public string Sku { get; set; }
}

I may present this to the UI in a more distilled format:

public class ProductViewModel
{
    public int Id { get; set; }

    public string Description { get; set; }
    public string Name { get; set; }
    public double Price { get; set; }
    public int Quantity { get; set; }
}

If this came from a repository of some kind, I'm simply calling:

var model = Mapper.Map<ProductViewModel>(productFromRepository)

Here I consistently get the view model I care about from the Product I've requested. If the business/service layer were to add/change/remove properties, I'd only go back to my Mapper.CreateMap<Product, ProductViewModel>() defintion, but the rest of my presentation logic would remain in-tact.

Upvotes: 1

Related Questions