Question

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

（通过数据存储类，我指的是一个负责将持久化对象读入内存或持久存储器内对象的类。）

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

它处理的对象类型;
是否加载和/或保留此类对象。

⇒可以调用加载Banana个对象的类，例如BananaSource。

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

存储库：这听起来很一般。这是否表示可以读/写的东西？
存储：这听起来像是可能允许写访问的内容。
上下文：听起来非常抽象。我用LINQ和对象关系映射器（ORM）看过这个 P.S。（几个月后）：这可能适用于包含“活动”或其他监督对象的容器（工作单元模式会浮现在脑海中）。
检索器：听起来像只读。
来源＆amp; sink ：可能不适合对象持久性;更适合数据流？
读者 / 作家：其意图非常清楚，但听起来对我来说太技术了。

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

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

Answer 1

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

仅仅为了记录，我几乎决定调用大多数数据存储类 存储库 。首先，它似乎是我建议的列表中最中立，非技术性的术语，它似乎与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。：自写完这个答案以来已经过去了一段时间，我在工作中有很多机会来审查别人的代码。我因此添加到我的词汇表中的一个术语是服务，我将其保留用于SOA场景：我可能会发布由私有支持的FooService Foo存储库或提供程序。 “服务”基本上只是一个薄薄的面向公众的层，它们负责处理身份验证，授权或聚合/批处理DTO以获得服务响应的正确“厚度”。

对象持久性术语：'存储库'与'存储'对比'上下文'与'检索者'对比（...）

1 个答案: