title: Object persistence terminology: 'repository' vs. 'store' vs. 'context' vs. 'retriever' vs. (...)
body: <p>I'm not sure how to name data store classes when designing a program's data access layer (DAL).</p>
  
  <p>(By <em>data store class</em>, I mean a class that is responsible to read a persisted object into memory, or to persist an in-memory object.)</p>
  
  <p>It seems reasonable to name a data store class according to two things:</p>
  
  <ul>
  <li>what kinds of objects it handles;</li>
  <li>whether it loads and/or persists such objects.</li>
  </ul>
  
  <p>&rArr; A class that loads <code>Banana</code> objects might be called e.g. <code>BananaSource</code>.</p>
  
  <p>I don't know how to go about the second point (ie. the <code>Source</code> bit in the example). I've seen different nouns apparently used for just that purpose:</p>
  
  <ul>
  <li><strong>repository</strong>: this sounds very general. Does this denote something read-/write-accessible?</li>
  <li><strong>store</strong>: this sounds like something that potentially allows write access.</li>
  <li><strong>context</strong>: sounds very abstract. I've seen this with LINQ and object-relational mappers (ORMs).<br />
  <em>P.S. (several months later): This is probably appropriate for containers that contain "active" or otherwise supervised objects (the Unit of Work pattern comes to mind).</em></li>
  <li><strong>retriever</strong>: sounds like something read-only.</li>
  <li><strong>source</strong> &amp; <strong>sink</strong>: probably not appropriate for object persistence; a better fit with data streams?</li>
  <li><strong>reader</strong> / <strong>writer</strong>: quite clear in its intention, but sounds too technical to me.</li>
  </ul>
  
  <p>Are these names arbitrary, or are there widely accepted meanings / semantic differences behind each? More specifically, I wonder:</p>
  
  <ul>
  <li>What names would be appropriate for read-only data stores?</li>
  <li>What names would be appropriate for write-only data stores?</li>
  <li>What names would be appropriate for mostly read-only data stores that are occasionally updated?</li>
  <li>What names would be appropriate for mostly write-only data stores that are occasionally read?</li>
  <li>Does one name fit all scenarios equally well?</li>
  </ul>