在 Web 应用程序中使用“商店”答案

【问题标题】：Use of "stores" within a web application在 Web 应用程序中使用“商店”
【发布时间】：2011-01-06 19:48:54
【问题描述】：

我看到我正在开发的网络应用程序中大量使用“存储”对象。这种模式有名称吗？你会说这些类型在 BLL 或 DAL 中吗？

这些存储包含我认为是经典 DAL 类型的片段，与单一类型相关联。

例如，我们有一个 TabStore，其中包含用于持久化和检索选项卡的方法。在 TabStore 的每个方法中，都有调用相应 NHibernate 查询的代码。

使用这种模式有哪些陷阱（如果有的话）？将曾经可能是单一的 Dal 类型分离为更易于管理、更小的类型真的是一种简单的尝试吗？

示例方法：

public IList<Tab> GetAllTabInstancesForUserId(Guid userId)
{
    IList<Tab> tabInstances =
                UoW.Session.CreateQuery("from Tab t where t.UserId=:userId order by t.TabOrder")
                   .SetGuid("userId", userId)
                   .SetCacheable(true)
                   .List<Tab>();

    return tabInstances;
}

【问题讨论】：

商店是一个非常模糊的词。如果您期望得到一个体面的答案，可能需要更多上下文。

标签： asp.net-mvc datastore

【解决方案1】：

它可能是更常见的Repository。

抽象存储库属于域模型，但应由单独的数据访问组件中的具体类实现。

【讨论】：

将数据访问组件简单地作为与业务逻辑位于相同 DLL 和命名空间中的类型（例如 TabRepository）是否有效？
有效性取决于您的需求和应用程序的复杂性，但即使是中等复杂性，我也建议不要这样做，因为在实践中很难确保松散耦合。在消费者和具体类型之间建立紧密耦合变得太容易了。

【解决方案2】：

如果我正确理解了这个问题，“存储”与 DAL 的关系比与 BLL 的关系更密切，因为它们中应该没有什么逻辑——毕竟它们的作用只是“存储”。

【讨论】：

【解决方案3】：

~~更多细节肯定会有所帮助，包括使用“商店”的代码 sn-ps...~~

但是根据您的问题，听起来开发人员使用术语“存储”而不是“存储库”，这意味着 Repository Pattern（与您的数据访问有关层）。

在您更新之后...开发人员最初所说的“商店”显然是一个“存储库”。

【讨论】：