对象持久性术语:'存储库'与'存储'对比'上下文'与'检索者'对比(...)

Question

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

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

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

• 它处理的物品类型;
• 是否加载和/或持久存在此类对象.

⇒ Banana可以调用加载对象的类,例如BananaSource.

我不知道如何处理第二点(即Source示例中的位).我见过不同的名词显然是出于这个目的使用的:

• 存储库:听起来很一般.这是否表示可读/写可访问的内容？
• store:这听起来像是可能允许写访问的东西.
• 上下文:听起来非常抽象.我用LINQ和对象关系映射器(ORM)看过这个.
  PS(几个月后):这可能适用于包含"活动"或其他监督对象的容器(工作单元模式会浮现在脑海中).
• 猎犬:听起来像只读的东西.
• source&sink:可能不适合对象持久性; 更适合数据流？
• 读者/作者:其意图非常清楚,但听起来对我来说太技术了.

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

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

Answer 1

由于还没有人回答这个问题,我会在此期间发布我已经决定的内容.

仅仅为了记录,我几乎决定调用大多数数据存储类存储库.首先,它似乎是我建议的列表中最中性,非技术术语,它似乎与存储库模式完全一致.

通常,"存储库"似乎很适合数据检索/持久性接口类似于以下内容:

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

我决定使用的另一个术语是提供程序,每当对象即时生成而不是从持久性存储中检索时,或者在纯粹读取时发生对持久性存储的访问时,我将更喜欢"存储库" - 只有这样.(工厂也是合适的,但听起来更具技术性,而且我已经决定反对大多数用途的技术术语.)

PS:自写这个答案以来已经过去了一段时间,我在工作中有很多机会来审查别人的代码.我在词汇表中添加的一个术语是Service,我将其保留用于SOA场景:我可能会发布一个FooService由私有Foo存储库或提供程序支持的版本."服务"基本上只是一个薄薄的面向公众的层,它们负责处理身份验证,授权或聚合/批处理DTO以获得服务响应的正确"粗略".