title: Decoupling backing store with Spring Web MVC
body: <p>This is a design pattern question, so I'll illustrate it with a simple example of an address book app.</p>
  
  <p>Firstly a few assumptions.
  1. It appears to be acceptable to directly use DB domain objects as the backing store for Spring MVC forms.</p>
  
  <p>Iteration 1 of my app I created a JPA mapped Person object with various attributes attached. Using the DAO pattern I created a persistence object which can getAll, store and delete people from the database. In addition I have a factory method, create, so I can get a person object. Using this DAO object I create a simple web front end. All is good.</p>
  
  <p>In iteration 2 I need to support multiple storage types, so I create an interface for person, which has multiple implementations, and an interface for the DAO persistence, again with multiple implementations. Also, person was extended to be able to have multiple addresses.</p>
  
  <pre><code>interface IPerson {
      public String getName();
      public List&lt;IAddress&gt; getAddresses();
  }
  </code></pre>
  
  <p>But, when it comes to updating the web interface to be able to deal with these multiple implementations I have an issue. The persistence implementation is injected by Spring. And, because that persistence object has a factory method I am all good for creating the IPerson implementation. But, if I want to do something fancy like allow multiple addresses be submitted as part of the one request then I have an issue. To allow this to work with Spring you seem to need to use an AutoPopulatingList, so spring can just .get(#) the record an copy the attributes in.</p>
  
  <p>So, one solution to making this work is to require all persistence implementations use an autopopulating list, and create the correct implementation for all child classes. Is this appropriate, given that we'd need to apply this @PostLoad with JPA as the base lists get replaced by Hibernate.</p>
  
  <p>The alternative is to not make any assumptions about the implementation passed into the persistence implementation and convert/copy the objects across to the appropriate type. This looks better, as then the Domain object are kept simple, and all the storage complexity is in the DAO. In this case we'd use a Default* implementation of the IPerson and IAddress interfaces.</p>
  
  <p>Even though I like the second option better, I am not necessarily comfortable with this situation. Can anyone offer any insights or advice?</p>