Object persistence terminology: 'repository' vs. 'store' vs. 'context' vs. 'retriever' vs. (...)

Question

I'm not sure how to name data store classes when designing a program's data access layer (DAL).

(By data store class, I mean a class that is responsible to read a persisted object into memory, or to persist an in-memory object.)

It seems reasonable to name a data store class according to two things:

• what kinds of objects it handles;
• whether it loads and/or persists such objects.

⇒ A class that loads Banana objects might be called e.g. BananaSource.

I don't know how to go about the second point (ie. the Source bit in the example). I've seen different nouns apparently used for just that purpose:

• repository: this sounds very general. Does this denote something read-/write-accessible?
• store: this sounds like something that potentially allows write access.
• context: sounds very abstract. I've seen this with LINQ and object-relational mappers (ORMs).
  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).
• retriever: sounds like something read-only.
• source & sink: probably not appropriate for object persistence; a better fit with data streams?
• reader / writer: quite clear in its intention, but sounds too technical to me.

Are these names arbitrary, or are there widely accepted meanings / semantic differences behind each? More specifically, I wonder:

• What names would be appropriate for read-only data stores?
• What names would be appropriate for write-only data stores?
• What names would be appropriate for mostly read-only data stores that are occasionally updated?
• What names would be appropriate for mostly write-only data stores that are occasionally read?
• Does one name fit all scenarios equally well?

Answer 1

As noone has yet answered the question, I'll post on what I have decided in the meantime.

Just for the record, I have pretty much decided on calling most data store classes repositories. First, it appears to be the most neutral, non-technical term from the list I suggested, and it seems to be well in line with the Repository pattern.

Generally, "repository" seems to fit well where data retrieval/persistence interfaces are something similar to the following:

public interface IRepository<TResource, TId>
{
    int Count { get; }
    TResource GetById(TId id);
    IEnumerable<TResource> GetManyBySomeCriteria(...);
    TId Add(TResource resource);
    void Remove(TId id);
    void Remove(TResource resource);
    ...
}

---

Another term I have decided on using is provider, which I'll be preferring over "repository" whenever objects are generated on-the-fly instead of being retrieved from a persistence store, or when access to a persistence store happens in a purely read-only manner. (Factory would also be appropriate, but sounds more technical, and I have decided against technical terms for most uses.)

P.S.: Some time has gone by since writing this answer, and I've had several opportunities at work to review someone else's code. One term I've thus added to my vocabulary is Service, which I am reserving for SOA scenarios: I might publish a FooService that is backed by a private Foo repository or provider. The "service" is basically just a thin public-facing layer above these that takes care of things like authentication, authorization, or aggregating / batching DTOs for proper "chunkiness" of service responses.

Answer 2

Well so to add something to you conclusion:

A repository: is meant to only care about one entity and has certain patterns like you did.

A store: is allowed to do a bit more, also working with other entities.

A reader/writer: is separated to allow semantically show and inject only reading and wrting functionality into other classes. It's coming from the CQRS pattern.

A context: is more or less bound to a ORM mapper as you mentioned and is usually used under the hood of a repository or store, some use it directly instead of making a repository on top. But it's harder to abstract.