The following code handles all of the above concerns / issues by wrapping the AutoMapper static instance up into a single bespoke mapping class. At a first glance this would appear to be a step backwards as it requires each object to object mapping to be defined as a method in the interface and implementing class. However for very little overhead or extra coding this comes with a benefit of abstracting the “how” of the mapping from the calling code. It would be easy to add another mapping framework into the Mapper class below and then update individual methods to use that new mapping framework. It also helps prevent any premature optimisations as the code can be deployed with new methods using mappings that provide the maximum automation and minimal manual configuration. If performance issues then arise during testing or live usage, individual methods/mappings can be tackled to provide better performance – which for maximum throughput if the situation required it could result in the mapping framework(s) being by-passed completely and all initialisation of the target class performed directly within the mapping method.
using am = Automapper;namespace Tools{public interface IMapper
{CustomerEntity MapCustomer(CreateCustomerMsg msg);
CustomerEntity MapCustomer(UpdateCustomerMsg msg);
}
public class Mapper : IMapper
{static Mapper()
{// All creation code in the static constructoram.Mapper.CreateMap<CreateCustomerMsg, CustomerEntity>();am.Mapper.CreateMap<UpdateCustomerMsg, CustomerEntity> ();
}
public CustomerEntity MapCustomer(CreateCustomerMsg msg)
{
return am.Mapper.Map<CreateCustomerMsg,CustomerEntity>(msg);
}
public CustomerEntity MapCustomer(UpdateCustomerMsg msg);
{
return am.Mapper.Map<(UpdateCustomerMsg,CustomerEntity>(msg);
}
}
}
No comments:
Post a Comment