1

I'm using AutoMapper in a generated Data Access Layer. That works fine. It was a little confusing when using AutoMapper in another layer and realizing the mappings created in the DAL with Mapper.CreateMap<T1, T2>() were still present. I see Mapper.Reset() which will remove these however I'd rather not have to have the other layers worry about the DAL. Would the best practice be to put a Mapper.Reset() before and after my mapping operations in the DAL? Or is there a way to give these DAL mappings a non-default key to let them persist but not interfere with the use of AutoMapper in other layers?

Note: The use of AutoMapper in the DAL has some specific options such as a number of .ForMember(...) calls that my other layers should not use (without a Mapper.Reset() they would reuse these options).

Cymen
  • 14,079
  • 4
  • 52
  • 72

1 Answers1

2

AutoMapper works as a singleton/single instance. Does it really matter though?

EDIT : This may help you Using Profiles in Automapper to map the same types with different logic

If your other layers aren't worried so much about the DAL classes chances are they aren't going to be calling Map on an instance of the DAL class anyway.

If you call Reset() then your DAL classes will need to restate them when they next need to do some mapping which will add extra very unnecessary overhead.

EDIT : If you call Reset at the start of every DAL call then you can only have a single threaded Data Access strategy. If you call Reset in the middle of a mapping for another DAL project then you are going to obviously break this - so you will have to lock on every DAL method.

This is not the way to use Automapper so I would be leaning towards either looking into those profiles, or not using it all together.

ALSO : Can you post a sample code for what is wrong with having lots and lots of multiple mappings going on? Are there different mapping strategies between two types depending on where in the DAL they are being called from?

Community
  • 1
  • 1
Dave Walker
  • 3,498
  • 1
  • 24
  • 25
  • Unfortunately, the DAL generated code is all there is in a lot of certain projects. So it looks like I'm stuck with Reset() before and after every Map call in the DAL. – Cymen Aug 01 '11 at 14:47
  • 1
    Actually this is opening up a whole can of worms doing this. Resetting is the incorrect way to use Automapper. In this instance I would either not use Automapper, or try use profiles. – Dave Walker Aug 02 '11 at 13:20
  • Is there another alternative if the use of Automapper is always between identical types (at least in the DAL) so ? I'll look into profiles. I do see it as a can of worms too. I can't realistically change how the DAL is used either. This is all in ASP.NET MVC so the threading shouldn't be an issue. I realized the DAL is all generated code so maybe it would be best to generate the equivalent of the Automapper calls and do away with it in the DAL layer. – Cymen Aug 02 '11 at 14:11
  • I've removed the use of AutoMapper from the DAL as it was clear it was using a small fraction of the AutoMapper features but incurring a huge overhead due to the way it was being used (with Mapper.Reset() being called so frequently). I went with reflection instead. Thanks! – Cymen Aug 03 '11 at 18:50
  • 1
    No worries! Even tho using MVC you will still have threading issues as there is only once instance of the AutoMapper. Glad to have helped. – Dave Walker Aug 08 '11 at 14:25