【问题标题】:When implementing the repository pattern should lookup value / tables get their own Repository?在实现存储库模式时,查找值/表应该获得自己的存储库吗?
【发布时间】:2009-07-22 21:40:06
【问题描述】:

我正在基于BISDM 的修改版本为多个数据库实体创建 RESTful 服务。其中一些实体具有关联的查找表,如下所示:

我决定使用存储库模式在数据持久性/检索之间提供清晰的分离;但是,我不确定在存储库中应该如何表示查找(而不是实体)。

查找应该有自己的存储库接口,与关联实体“共享”一个,还是应该有一个通用的 ILookupRepository 接口?

目前,这些查找是只读的;但是,有时我们可能希望通过服务编辑查找。

Option 1:
   ISpaceRepository.GetSpaceCategoryById(string id);
Option 2:
   ISpaceCategoryRepository.GetById(string id);
Option 3:
   ILookupRepository.GetSpaceCategoryById(string id);

顺便说一句,这个问题与另一个关于look-up tables & RESTful web services的问题有关。

【问题讨论】:

    标签: repository-pattern lookup-tables


    【解决方案1】:

    没有。存储库应该代表领域模型概念,而不是实体级别的概念,当然也不是数据库级别。考虑一下您希望对域的给定组件(例如空间)执行的所有操作。

    您想要做的事情之一是 GetSpaceCategories()。这绝对应该包含在 Spaces 存储库中,因为任何处理 Spaces 的人都希望访问 Space 类别,而无需实例化其他存储库。

    我认为通用存储库会适得其反。将存储库视为实用程序类实际上可以保证任何中等复杂的操作都必须实例化两个存储库。

    【讨论】:

    • 使用这种方法,UpdateSpaceCategory(SpaceCategory spaceCategory) 和 DeleteSpaceCategory(string id) 也会在 ISpaceRepository 中,对吗?
    • 当然。存储库的目的是隐藏底层数据访问。如果您要切换数据库层,程序的其余部分仍将在存储库上调用 GetCategories() 或 UpdateCategory() - 更改对存储库使用者是透明的。
    猜你喜欢
    • 2011-05-24
    • 2011-09-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-11-17
    • 1970-01-01
    • 2012-03-30
    相关资源
    最近更新 更多