代码之家 › 专栏 › 技术社区 › stakx - no longer contributing Saravana Kumar

对象持久性术语:“存储库”vs.“存储”vs.“上下文”vs.“检索器”vs.(…)

data-access-layer datasource terminology persistence naming-conventions

26

stakx - no longer contributing Saravana Kumar · 技术社区 · 16 年前

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

(由 数据存储类

根据以下两点命名数据存储类似乎是合理的:

它处理什么样的物体;
是否加载和/或持久化这些对象。

加载的类 Banana BananaSource .

我不知道第二点该怎么说 Source 位)。我见过不同的名词显然是为了这个目的:

:这听起来很一般。这是否表示可以读写的东西?
:这听起来像是可能允许写访问的东西。
:听起来很抽象。我在LINQ和对象关系映射器(ORMs)中看到了这一点。
寻回犬 :听起来像是只读的。
下沉
/ :它的意图很清楚,但对我来说听起来太技术化了。

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

1 回复 | 直到 15 年前

1

17

stakx - no longer contributing Saravana Kumar 10 年前

由于还没有人回答这个问题,我将把我的决定张贴在网上。

存储库 . 首先,它似乎是我建议的列表中最中性、非技术性的术语,而且似乎与 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);
    ...
}

供应商 ,无论何时动态生成对象而不是从持久性存储中检索对象,或者以纯只读方式访问持久性存储时,我都会倾向于使用“repository”而不是“repository”( 这也很合适,但听起来更专业,我已经决定反对大多数使用技术术语。)

附笔。: 写下这个答案已经有一段时间了,我在工作中有好几个机会来检查别人的代码。我在词汇量中增加的一个术语是服务 ,这是我为SOA场景保留的:我可能会发布一个 FooService Foo