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?