对象持久化术语：'repository' vs. 'store' vs. 'context' vs. 'retriever' vs. (...)

Question

在设计程序的数据访问层 (DAL) 时，我不确定如何命名数据存储类。

（通过数据存储类，我的意思是负责将持久化对象读入内存或持久化内存中对象的类。）

根据两点来命名数据存储类似乎是合理的：

• 它处理什么样的对象；
• 是否加载和/或保留此类对象。

⇒ 加载Banana 对象的类可能被称为例如BananaSource.

我不知道如何处理第二点（即示例中的Source 位）。我已经看到显然用于此目的的不同名词：

• repository：这听起来很笼统。这是否表示可以读/写访问？
• store：这听起来像是允许写访问的东西。
• 上下文：听起来很抽象。我已经在 LINQ 和对象关系映射器 (ORM) 中看到了这一点。
  P.S. （几个月后）：这可能适用于包含“活动”或其他受监督对象的容器（想到工作单元模式）。
• retriever：听起来像是只读的。
• source & sink：可能不适合对象持久化；更适合数据流？
• reader / writer：意图很明确，但对我来说听起来太技术性了。

这些名称是任意的，还是每个名称背后都存在广泛接受的含义/语义差异？更具体地说，我想知道：

• 什么名称适合只读数据存储？
• 什么名称适合只写数据存储？
• 什么名称适合偶尔更新的只读数据存储？
• 什么名称适合偶尔读取的大多数只写数据存储？
• 一个名称是否同样适用于所有场景？

Answer 1

由于还没有人回答这个问题，我将在此期间发布我的决定。

为了记录，我几乎决定调用大多数数据存储类repositories。首先，它似乎是我建议的列表中最中性、非技术性的术语，并且似乎与Repository pattern 非常吻合。

通常，“存储库”似乎非常适合数据检索/持久性接口类似于以下内容的情况：

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);
    ...
}

---

我决定使用的另一个术语是 provider，当对象是动态生成而不是被检索时，我会更喜欢“存储库”来自持久性存储，或者当以纯只读方式访问持久性存储时。 （Factory 也是合适的，但听起来更具技术性，我决定在大多数情况下不使用技术术语。）

P.S.： 写完这个答案已经过去了一段时间，我在工作中有几次机会审查别人的代码。因此，我添加到我的词汇表中的一个术语是 Service，这是我为 SOA 场景保留的：我可能会发布一个由私有 @987654324 支持的 FooService @ 存储库或提供者。 “服务”基本上只是这些之上的一个面向公众的薄层，负责处理身份验证、授权或聚合/批处理 DTO 等事情，以实现服务响应的适当“块状”。