Using AutoMapper with EF6 DbFirst and Stored Procedure (complex types)

Question

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. ie 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>();

Answer 1

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.