title: Repository design pattern - should there be one repo for every Dao?
body: <p>i have a few DAOs in my app which access a database for CRUD operations.  Lets say there News, weather and , sports DAO.  So im confused on how many Repositories i would need.  should i just use one repository say DataRepository and let me hold my database and all dao's. and encapsulate methods for the CRUD operations in it ? or should each DAO have its own repository ?  </p>
  
  <p>I mean a repository should return only data objects that the calling layer understands. so its like a encapsulation over the DAOs but im not sure if i should create one per DAO or just have one repo per app, etc.   </p>
  
  <p>If you read this <a href="http://hannesdorfmann.com/android/evolution-of-the-repository-pattern" rel="nofollow noreferrer">article</a> we begin to understand that the pattern is over engineered or over abstracted. Its turned into hiding detail vs minimizing query statements. </p>
  
  <p>But it seems There should be a Repo per DAO as the interface itself looks like this:</p>
  
  <pre><code>interface Repository&lt;T&gt; {
  void add(T item);
  void remove(Specification specification);
  List&lt;T&gt; query(Specification specification);
  </code></pre>
  
  <p>}</p>
  
  <p>where T can be the type/table of data DAO accesses. Just need clarification now. Can you imagine i have 30 different types, so then i need 30 different Repo implementations. this is ridiculous.  It seems the repository pattern itself is like a DAO, no different.  im so confused. </p>