命名约定 – 对象持久性术语：’存储库’与’存储’与’上下文’与’检索者

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

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

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

>它处理什么样的对象？
>是否加载和/或保持这些对象。

⇒加载香蕉对象的类可能被称为例如。 BananaSource。

我不知道如何去第二点(即例子中的源位)。我看到不同的名词显然用于这个目的：

仓库：这听起来很普遍。这是否表示读/写可访问的东西？
> store：这听起来像是允许写访问的东西。
>上下文：听起来很抽象。我已经看过LINQ和对象关系映射器(ORM)。
附： (几个月后)：这可能适用于包含“主动”或其他受监督对象的容器(请注意工作单位)。
> retriever：听起来像只读的东西。
>来源& sink：可能不适合对象持久化;更好地适应数据流？
读者/作家：其意图相当清楚，但对我来说听起来太技术性了。

这些名称是否是任意的，还是有广泛接受的含义/语义差异？更具体地说，我想知道：

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

由于没有人回答这个问题，我会在同一时间内决定的。

只是为了纪录，我几乎决定调用大多数数据存储类库。首先，它似乎是我建议的列表中最中立的非技术性术语，似乎与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);
    ...
}

我决定使用的另一个术语是提供者，我会喜欢“存储库”，只要对象是生成的，而不是从持久性存储中检索，或者当访问持久性存储发生在纯读 – 方式。 (工厂也是适当的，但听起来更具技术性，而且我已经针对大多数用途的技术术语做出了决定。)

P.S：自写这个答案以来已经有一段时间了，我在工作中有几个机会来审查别人的代码。我已经添加到我的词汇中的一个术语是Service，我正在为SOA场景预留：我可能会发布一个由私人Foo存储库或提供商支持的FooService。 “服务”基本上只是一个薄薄的面向公众的层面，可以处理身份验证，授权或聚合/批量的DTO，以便正确的“服务”响应。