1

In my application, I have these projects within a solution:
(1) an ASP.net core api
(2) .NET core class library containing an EF core DbContext and Repository class to be used by the API project and
(3) Another .NET core class library that contains nothing but model classes (so as to define them once)

I'd like to use Automapper, but typical examples involve setting up the mapping in the startup of the containing application eg. ConfigureServices etc. With my approach, I want to contain this within my class library. Where would be a good place to put the mapping in this case? Put it in its own method of the Repository class and call this method from the constructor?

[ update ]
In my case it doesn't seem that a mapping library such as this wont really offer any added benefit, since its rare that any two areas (at most) of the application would return or consume the same mapped objects. My repository is where linq queries are made against the DbContext and projected into domain models. Some of these queries can be non-trivial and doing this within the constraints of yet another mapping layer wouldn't seem to serve the purpose of being a central place where all the mappings take place, since that mapping is only to be done once or twice at most.

bitshift
  • 6,026
  • 11
  • 44
  • 108
  • 1
    See the comments and the answer https://stackoverflow.com/questions/50635558/configuring-automapper-in-n-layer-application. – Lucian Bargaoanu Sep 06 '18 at 14:38
  • 1
    Mapping inherently requires information about the source *and* destination. As a result, it's not suitable to be inside a class library, as it would require knowledge of the application that would need to use that class library. Your view models, for example, belong to your web app, while the entities belong to the class library, as a result, the mapping also belongs in the web app, because that is the place where both sides can be seen. – Chris Pratt Sep 06 '18 at 15:08
  • @Chris - So, in this case my options could be (1) Return Db entities from the class library (as opposed to models) and map them to model classes in the API project code or (2) use the approach I listed above but without an object mapper, just simply projecting results into model classes from within the class library methods. – bitshift Sep 06 '18 at 15:45
  • 1
    I'm saying the question is kind of moot. If your mapping remains with your API, then you can use DI to get your mapper. FWIW, your context should likely go with your entities in the same project, and the repo can go in the trash. You don't need it and shouldn't be using it with an ORM like EF. – Chris Pratt Sep 06 '18 at 16:48

0 Answers0