title: How to implement Data Mapper / Repository persistence patterns for diverse data sources?
body: <p>I am writing a new website project pretty much from scratch. The project is in C# but my background is in PHP (the pseudo-code below is a bit if a mixture, trying to be both succinct and declarative).</p>
  
  <p><strong>The problem</strong></p>
  
  <p>I need to retrieve configuration data from one of two places - sometimes from the local Database and sometimes from a Soap service. I should be able to create the same set of Model objects from either source.</p>
  
  <p>The data is stored in completely different structures in the different data sources - several different Soap responses need to be pieced together from the Soap end, whereas the DB structure is much closer to how I'm structuring my Model objects in the code.</p>
  
  <p>The configuration is made up of a tree of objects: <em>Products</em> contain <em>Properties</em> which contain <em>Options</em> which have <em>Conditions</em> for when they apply.</p>
  
  <p><strong>The goals</strong></p>
  
  <p>I want to separate concerns as much as possible (to hopefully facilitate both test-/maintain-/extend-ability):</p>
  
  <ul>
  <li>My Model objects should know nothing about Data Persistence or retrieval</li>
  <li>The Data Persistence object should, as far as possible, be agnostic about the exact type of Data Source</li>
  <li>I want to separate object creation out as much as possible.</li>
  </ul>
  
  <p><strong>Questions</strong></p>
  
  <p>I'm aware of various design patterns around this (although I'm not entirely sure I understand them entirely). I <a href="https://softwareengineering.stackexchange.com/questions/170295/how-should-i-architect-my-model-and-data-access-layer-objects-in-my-website/170297">asked a question on Programmers</a> similar to this and got a response about <a href="https://stackoverflow.com/questions/1974735/what-exactly-is-persistence-ignorance">Persistence Ignorance</a> (<a href="https://stackoverflow.com/questions/905498/what-are-the-benefits-of-persistence-ignorance">more here</a>) and the <a href="http://msdn.microsoft.com/en-us/library/ff649690.aspx" rel="nofollow noreferrer">Repository</a> pattern, which both seem to be concepts from the Microsoft world.</p>
  
  <p>As far as I can tell "Persistence Ignorance" is simply the concept of having Model objects that know nothing about your Data Storage mechanism, and the Repository pattern seems very similar to the Data Mapper pattern, except that it <a href="https://stackoverflow.com/questions/804751/what-is-the-difference-between-the-data-mapper-table-data-gateway-gateway-da#answer-814479">may be more of a facade</a>, hiding more of what's actually going on.</p>
  
  <p>So my questions are:</p>
  
  <p><em>In the Data Mapper pattern should I have one Mapper per Model object? Rather than having one for the entire configuration tree?</em></p>
  
  <p>And therefore, should I have a configuration tree building object that uses all those Mapper objects?</p>
  
  <pre><code>class ConfigBuilder() {
      public ConfigBuilder (productMapper, propertyMapper, optionMapper, conditionMapper) {
          // save them into local properties
      }
  
      public Products() {
         var products = productMapper.FetchAll();
  
         foreach (var product in products) {
             AddProperties(product);
         }
  
          return products;
      }
  
      private AddProperties(products) { /* ... */ }
      private AddOptions(property) { /* ... */ }
      private AddConditions(option) { /* ... */ }
  }
  </code></pre>
  
  <p>Does this seem like a good solution?</p>
  
  <p><em>Where should the logic to build the objects be located?</em></p>
  
  <p>At some point there needs to be a considerable amount of logic to build my configuration objects from the random array of XML data that I get back from the Soap service, and a smaller amount of logic to do the same from the database.</p>
  
  <p>Should I be putting the logic to build the objects in separate instances of the Mapper objects?</p>
  
  <pre><code>interface IProductMapper { FetchAll; FetchByCode; Create; Delete; Update  }
  
  class ProductMapperXml implements IProductMapper {
      public ProductMapperXml(xmlDataSource) {}
      public FetchAll() { /* A whole bunch of logic to create the Product objects from XML data source */ }
  }
  
  class ProductMapperDatabase implements IProductMapper {
      public ProductMapperDatabase(databaseConnection) {}
      public FetchAll() { /* Select and build products from the database */ }
  }
  </code></pre>
  
  <p>Is this okay? Should this logic be abstracted further? If so why? Also, I'm a bit uneasy about the <code>ProductMapperXml</code> object having considerable logic itself and also being responsible for creating <code>Product</code> objects internally. Should I be passing it a <code>ProductFactory</code> of some sort? Or just use a factory method?</p>
  
  <p>Please please let me know if there are more elegant ways to solve this than my suggestions? Also if there are any layers of abstraction or Design Patterns I could benefit from that I've missed?</p>