title: How to map to internal properties using Automapper?
body: <p>we've been using Automapper for sometime and we think it is great utility, thanks for creating it!</p>
  
  <p>However, we have a question: </p>
  
  <p><strong>Question</strong></p>
  
  <p>"How do you configure AutoMapper to map a source property to an internal destination property?"</p>
  
  <p><strong>Background</strong></p>
  
  <p>In our layered architecture, Dto objects never leave the Data Access layer, only Domain objects are allowed to pass in and out of the Data Access layer. Thus, from a domain POV, domain objects shouldn't contain any database knowledge. However, in reality database Ids are very useful to carry around - expect the 'business-layer' developer shouldn't  know about them.</p>
  
  <p>Solution: add the database Ids to the domain object but market them as internal so that they aren't exposed to the 'business-layer'. Next expose the Common layer (which owns the domain objects) internals to the Data Access layer. Problem solved. Expect we can't figure out how to get Automapper (> v3.3.0) to work with our internal properties.</p>
  
  <p>In, version 3.3.0 <code>BindingFlags</code> were exposed, which use to solve the problem.</p>
  
  <p><strong>Example</strong></p>
  
  <p>Common.Dll</p>
  
  <pre><code>public class Person
  {
     public Parent Father { get; set; }
     internal int FatherId {get; private set; }
  }
  </code></pre>
  
  <p>DataAccess.dll</p>
  
  <pre><code>internal class PersonDto
  {
     public ParentDto Father { get; set; }
     public int FatherId {get; private set; }
  }
  </code></pre>
  
  <p>In our Profile class we have <code>CreateMap&lt;PersonDto, Person&gt;();</code></p>
  
  <p><em>Edit 1</em> - Fixed a typo in the return type of Father.</p>
  
  <p><em>Edit 2</em> - Added more info..</p>
  
  <p>In the Common.Dll, we have Services something like this:</p>
  
  <pre><code>public class ParentService
  {
      public Parent GetFather(Person person)
      {
          return repo.Parents.FirstOrDefault(parent =&gt; parent.Id = person.Father.Id);
      }
  }
  </code></pre>
  
  <p>And in the Business.Dll we have developer's using the Services something like this:</p>
  
  <pre><code>var father = parentService.GetFather(son);
  // use father separately or assign it to the son. Like so:
  // son.Father = father;
  </code></pre>
  
  <p>The whole point is, we don't want the business developer's to have access to <code>son.FatherId</code> from the Businssess.Dll nor do they have access to the Dto object that created the domain object. </p>
  
  <p>Thus, all the 'database' knowledge is encapsulated within in the various Common.dll Services or in the DataAccess.dll.</p>
  
  <p>Thanks.</p>