I'm beginning AutoMapper and had a question. I came across sample code like this:
Automapper.Mapper.CreateMap<Book, BookViewModel>()
.ForMember(dest => dest.Author,
opts => opts.MapFrom(src => src.Author.Name));
So this would let me convert a book to a book model, and then map the src to the src.author.name property because there was not a 1-1 mapping.
To confirm, it does not work in reverse on its own, meaning I now need to explicitly do this:
Mapper.Mapper.CreateMap<BookViewModel, Book>()
.ForMember(dest => dest.Author.Name,
opts => opts.MapFrom(src => src.Author));
Is that correct? So to further confirm, if I had 50 view models and views, I'd literally need 100 (one for the way in, one for the way out, plus any additional lines of code in the .ForMember expression)
Is this true? Is this a common practice (i.e. you could potentially see hundreds of lines of code to handle the field mapping back and forth for multiple DTOs with properties that do not match up 1-1)?
CreateMap creates a mapping for AutoMapper to use later when required. This is required only once in the lifetime of your Application. In order to make use of this mapping you have defined, you just need to call Automapper.Map method. Thus you don't have to create the mapping again and again.
Example:
var myBookViewModel = Automapper.Map<Book, BookViewModel>(myBook);
You are correct saying that defining a mapper for Book to BookViewModel will not make Automapper to create a mapper for BookViewModel to Book automatically for you. You have to create the mapper.
In essence yes, you'd need basically to specify both back and forth configurations to handle each DTO mapping. Without a deterministic pattern it is impossible to guess how the mapping would work between complex object when members' names are different, or when the properties you want are further within other objects, like in your example.
However, Automapper is fairly smart if you follow some basic patterns. In your case, if you change the DTO property name to AuthorName instead of Author, the CreateMap will properly map without having to specify the mapping manually (they call this "Flattening"). Automapper will even map methods to properties if they follow a GetProperty() => Property { get; set; } pattern. Renaming your DTO properties to follow this pattern could probably save you a bunch of lines. Take a look at their starters guide for other ways to simplify your mappings.
Related
I have a domain model that contains a collection and I want to use AutoMapper to map the parent and children to the view model but I don't want children that have been "soft" deleted to be taken across. For instance:
public class Customer {
public EntitySet<Order> {get;set;}
}
public class Order {
public DateTime? DeletedDate {get;set;}
}
my AutoMapper definition would be
Mapper.CreateMap<Customer, CustomerViewModel>();
Mapper.CreateMap<Order, OrderViewModel>();
and I don't want Orders to be in the view model that have a value for DeletedDate.
Is that possible in AutoMapper? Many thanks in advance,
Steve.
I came across similar issue and finally the approach similar to the one below worked for me:
Mapper.CreateMap<Customer, CustomerViewModel>()
.ForMember(dest => dest.Orders,
opt => opt.MapFrom(src => src.Orders.Where(o => !o.DeletedDate.HasValue)));
This assumes your Customer entity and CustomerViewModel dto have collections named "Orders".
This sounds like it would be a good fit for a custom ValueResolver. It will allow you to do your logic checks in an isolated fashion. I don't have Visual Studio in front of me right now, but I can add some sample code later if you'd like.
EDIT:
After tinkering with this I don't think a ValueResolver is the way to go. I was able to get it to work by using the following conditional configuration for the Order mapping:
Mapper.CreateMap<Order, OrderViewModel>()
.ForAllMembers(opt => opt.Condition(src => !src.DeletedDate.HasValue));
The only thing with this is that theOrderViewModel will still come over but it will be null. In other words if you had 3 orders, and one had a deletion date, then the number of orders you will have in your view model will still be 3, but the deleted value will be null. I'm guessing it would be best to just have 2, but I'm not seeing a clear way to do that right now.
Here's a post with a response from the author of AutoMapper that talks about a Skip method, but I wasn't able to see that feature in the latest release that I'm using.
I'm writing a few simple extension methods to create DTOs out of entities defined in the domain, however, those entities have properties that are also entities, and I'd like to be able to write something (that I personally find elegant) like they do in EF Core with Include().ThenInclude().
Ideally I'd like to be able to write something like
return myEntity.ToDto().Include(entity => entity.SubEntity).ThenInclude(subEntity => subEntity.AnotherSubEntity);
Is it possible?
The idea is that if I just call ToDto() I would simply receive a basic DTO object where all simple type properties are set but all complex type properties are null, unless I specify that I want to inclue one (or more) of the properties too.
AutoMapper Queryable Extensions provides a convenient way to query entities with relationships and map them to DTOs in one step.
It produces an optimized SQL query needed to copy that data.
Example:
var config = new MapperConfiguration(cfg => {
cfg.CreateMap<BlogDTO, Blog>().ReverseMap();
cfg.CreateMap<PostDTO, Post>().ReverseMap();
});
return _context.Blogs.Where(b => b.Id == Id)
.Include(x => x.Posts)
.ProjectTo<BlogDTO>(config)
.ToList();
I've actually managed to do it by sort of copying how EF Core does it with a lot of reflection and expression trees, and by creating my own visitor to then process the whole expression tree.
I am now able to write code like: myEntity.AsDtoable().Include( x => x.ComplexTypeProp ).ThenInclude( x => x.AnotherComplexTypeProp ).ToDto< EntityDto >();
We recently implemented automapper and currently looking to optimise assigning values from the DTO to model. currently we are doing something like
model.Property1 = dto.Property1;
model.SomePropertyType = dto.PropertyType;
model.Property2 = dto.Property2;
Now this could go pretty long and repetitive task to all Mapper classes.
Is there a way to simplify this on AutoMapper?
If you are using Automapper then have you not defined the maps (profile)? I believe, you might have defined those so please use those to instruct Automapper how to map source object to Target.
Another point Automapper also works based on naming convention, so if you have same property name in both source and target then it will automap automatically. So you don't unnecessary define the mapping fort it. To override mapping for a property (or whose name/type does not match), you can use .ForMember method.
cfg.CreateMap<MyDTO, MyModel>()
.ForMember(destination => destination.PropertyType,
opts => opts.MapFrom(source => source.SomePropertyType ));
You can read about Automapper at here.
Now in the code to get the mapped object, use it like
Mapper.Map<MyModel>(object of MyDTO);
I am using Entity Framework 6 DBFirst, MVC5 and AutoMapper.
I have 2 tables, Customers and CustomerContacts
For each class I have in Entity Framework EDMX (auto-generated) I have a Model class with the exact same properties. i.e. Customer => Model.Customer, CustomerContact => Model.CustomerContact. This is why I use AutoMapper.
Question 1: Since my Customer_Get stored procedure returns an auto-generated complex type (Customer_Get_Result) would most people make an additional model class for this also? (Model.Customer_Get_Result.cs) Or are all of the properties supposed to get combined adding everything to Model.Customer?
Question 2: Is the way I am handling mapping for Customer Contacts below correct? Mostly every property in Model.Customer is exactly the same as the AutoGenerated EF6 DBFirst file except for this which I placed in Model.Customer:
public List<CustomerContact> Contacts { get; set; }
In the end I want to be able to use Customer.Contacts to automatically get a list of all that Customer's contacts
In my AutoMapper I am trying to do something like this but don't think this is correct:
CreateMap<Customer, Model.Customer>()
.ForMember(dest => dest.Contacts, opt => opt.MapFrom(src => src.CustomerContact));
//map for customer getlist stored proc which will be returning several fields
//such as TotalCount, RowNumber, fields from a bunch of other tables
CreateMap<Customer_Get_Result, Model.Customer>();
For a stored procedure's complex type (Customer_Get_Result) would most
people make an additional model class for this also?
If it is exactly same properties as Customer, then I probably wouldn't create a model just for it, and just map it to the existing model.
Although it depends on what you are doing with this Model class, and whether the use case for the data mapped from the entity is any different than the data mapped from the stored procedure. Model's are just a fancy term for POCO. Models are often one of two things. A simplification of the entity, that is closer to a POCO than the EF entity is; such as DTO's you might use between your business layer and database layer. Or it is a specialization for a particular context, such as a ViewModel that has only properties needed for a particular view and often includes things like data annotations that are UI specific.
It depends alot on how your application is layered and what part of the application is retrieving data, and what it plans to do with that data. That said, I'd probably start with just using the same Model and see if I feel a need to rafactor later(but you'll still need 2 mappings, one from SP_Complex_Type -> Model, and one Entity -> Model).
Looks like your DB/EF model only has a single related contact from Customer.CustomerContact, but your model has a one-to-many relationship Model.Customer.Contacts. I'm basing this only on the plurality of the property name since you didn't give us any declarations of your entity. Either way there's a mismatch on the relationship your EF entity supports versus the relationship your Model supports. There's alot of different things you can do here with AutoMapper, but you can't make that decision until you figure why one has a list of related contacts, and the other only has a single related contact.
CreateMap<Customer, Model.Customer>()
.ForMember(dest => dest.Contacts, opt => opt.MapFrom(src => src.CustomerContact));
When mapping a list to a list, and the properties are named differently, then the above is exactly what you would do. Additionally if the types in each list are different, then you need to make sure your previously declared a map for those types as well. For example, if you are going from List<CustomerContactEntity> to List<CustomerContactModel> then you need to have already done a CreateMap<CustomerContactEntity,CustomerContactModel> to tell AutoMapper it can convert these types. This way as it encounters each item in the list, it will see that it has a mapping for that child type.
I am using AutoMapper to map DTOs to entities.
When creating the maps, I always end up ignoring the relationships of the entities, and that usually result in a long, long list. That is:
Mapper.CreateMap<CUSTOMER_DTO, CUSTOMER_ENTITY>()
.ForMember(m => m.ORDERS, o => o.Ignore())
.ForMember(m => m.PAYMENT_METHODS, o => o.Ignore());
// And on and on!
Is there a way I can just indicate AutoMapper to ignore every relationship in my entities? Many thanks.
I'm assuming here that your DTOs are simply missing the relationships and you have to ignore them all by hand. If it's the case, this other answer will be helpful. You could just do:
Mapper.CreateMap<CustomerDto, CustomerEntity>().IgnoreAllNonExisting();
And it would ignore every property in CustomerEntity that's not present in CustomerDto.
As a side note: you should probably change the all-caps names for classes and properties to pascal cased, to follow the general C# coding conventions.