title: Implementation of Repository Pattern in Python?
body: <p>Mainly out of curiosity, I'm looking for a Python framework or example for the Repository Pattern of decoupling persistence logic from domain logic. </p>
  
  <p>The name "Repository Pattern" appears in the post "<a href="http://www.braintreepayments.com/devblog/untangle-domain-and-persistence-logic-with-curator" rel="noreferrer">Untangle Domain and Persistence Logic with Curator</a>" (Ruby), idea comes from a <a href="http://domaindrivendesign.org/node/123" rel="noreferrer">section</a> of the "Domain-Driven Design" book and <a href="http://martinfowler.com/eaaCatalog/repository.html" rel="noreferrer">Martin Fowler</a>.  The model class contains no persistence logic, rather the app declares repository subclasses whose instances act like in-memory collections of model instances.  Each repository persists the model in different ways, for example to SQL (various schema conventions), to Riak or other noSQL and to memory (for caching).  Framework conventions mean repository subclasses typically require minimal code: just declaring "WidgetRepository" subclass of SQLRepository would provide a collection that persists the model Widget to the DB table named "widgets" and match columns to Widget attributes.</p>
  
  <p>Differences from other patterns:</p>
  
  <p><strong>Active Record Pattern</strong>: for example, Django ORM.  The application defines just the model class with domain logic and some metadata for persistence.  The ORM adds persistence logic to the model class.  This mixes domain and persistence in one class (undesirable according to the post).</p>
  
  <p>Thanks to @marcin I see that when  Active Record supports diverse backends and .save(using="other_database") function, that gives the multi-backend benefit of the Repository Pattern.  </p>
  
  <p>So in a sense Repository Pattern is just like Active Record with the persistence logic moved to a separate class.</p>
  
  <p><strong>Data Mapper Pattern</strong>: for example, SQLAlchemy's Classical Mappings. The app defines additional classes for database table(s), and data mapper(s) from model to table(s).  Thus model instance can be mapped to tables in multiple ways e.g. to support legacy schemas.   Don't think SQLAlchemy provides mappers to non-SQL storage.</p>