对象持久性术语：“存储库”与“商店”相比与“上下文”相对vs. 猎犬与 (...)

Question

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

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

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

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

⇒ 加载 Banana 对象的类可能被称为 BananaSource。

我不知道如何处理第二点（即示例中的 Source 位）。我见过明显用于此目的的不同名词：

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

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

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

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

---

我决定使用的另一个术语是provider，我将其当对象是动态生成而不是从持久性存储中检索时，或者当对持久性存储的访问以纯只读方式发生时，优先于“存储库”。 （Factory 也合适，但听起来更具技术性，我已经决定在大多数用途中不使用技术术语。）

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

Answer 2

好吧，为您的结论添加一些内容：

存储库：意味着只关心一个实体，并且像您一样具有某些模式。

商店：可以做得更多，也可以与其他实体合作。

读取器/写入器：分离以允许在语义上仅显示读取和写入功能并将其注入到其他类中。它来自 CQRS 模式。

上下文：正如您提到的，或多或少与 ORM 映射器绑定，通常在存储库或存储的底层使用，有些直接使用它而不是在顶部创建存储库。但抽象起来比较困难。