naming-conventions - 对象持久性术语 : 'repository' vs. 'store' vs. 'context' vs. 'retriever' vs. (...)

Question

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

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

根据两件事来命名数据存储类似乎是合理的:

它处理什么样的对象；

它是否加载和/或持久化此类对象。

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

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

存储库 : 这听起来很笼统。这是否表示可以读/写访问？

店铺 :这听起来像是可能允许写访问的东西。

上下文 : 听起来很抽象。我已经在 LINQ 和对象关系映射器 (ORM) 中看到了这一点。
附言(几个月后):这可能适用于包含“事件”或其他受监督对象的容器(想到工作单元模式)。

猎犬 : 听起来像是只读的。

来源 & 水槽 :可能不适合对象持久性；更适合数据流？

读者 /作家 : 它的意图很清楚，但对我来说听起来太技术性了。

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

什么名称适合只读数据存储？

什么名称适合只写数据存储？

什么名称适合偶尔更新的只读数据存储？

什么名称适合偶尔读取的大多数只写数据存储？

一个名字是否同样适合所有场景？

Answer 1

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

仅作记录，我几乎决定调用大多数数据存储类 存储库 .首先，它似乎是我建议的列表中最中性、非技术性的术语，并且似乎与 Repository pattern 非常一致。 .

通常，“存储库”似乎非常适合数据检索/持久性接口(interface)类似于以下内容的地方:

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

我决定使用的另一个术语是 供应商 ，当对象是动态生成而不是从持久性存储中检索时，或者当以纯只读方式访问持久性存储时，我将更喜欢“存储库”。 ( 工厂 也是合适的，但听起来更具技术性，我已决定在大多数用途中不使用技术术语。)

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