数据访问模式类似于存储库但不完全

Posted 2023-02-24

【中文标题】数据访问模式类似于存储库但不完全

【英文标题】：Data Access Pattern Like Repository but Not Completely

【发布时间】：2012-09-19 18:32:20

【问题描述】：

我正在使用一个保存数据的系统开展一个项目，我正在考虑使用数据访问方法来获取数据，以便将其交给我在事物表示方面的组件。我认为这是一个 N 层架构。这是我的想法：

表示层（WebForms 和用户控件）

   \/

数据访问层（这是我的问题所在）

   \/

业务对象（系统中每个实体的 C# 类）

   \/

用于从数据库获取数据的现有 API（MS SQL 驱动）

在我的 DAL 中，我想使用系统中的特定 API 机制来获取业务对象，以便将它们传递给我的演示组件。我知道我创建各种实用程序存储库类以“获取一堆 X 业务对象”的存储库模式。例如。假设我有一个名为Article 的业务对象，我可以有一个ArticleRepository，我的“文章列表页面”将调用该存储库并为我获取Article 的集合。这很好，但对我来说在 DAL 上可能有点矫枉过正。是否有其他名称，例如在我的业务对象上使用 static GetAll() 方法？所以不是：

var repo = new ArticleRepository();
IEnumerable<Article> articles = repo.GetAll();

我在想这样简单的事情：

IEnumerable<Article> articles = Article.GetAll();

Article 类既是我的具有相关属性甚至辅助方法的业务对象，也有一个static GetAll() 方法。这种方法有名称吗？创建这个精简的伪存储库是不是一个坏主意？

我问这一切是因为简单地说，我将有很多存储库类来执行此操作，因为我有很多业务对象，所有这些对象都有独特的查询来从系统中获取它们。

【问题讨论】：

我认为您的业务对象应该与您的数据访问分开，因此您不应该在业务类中包含数据访问方法

将数据访问行为编码到您的业务对象中使得以后很难进行更改，破坏了关注点分离原则等。 Article 类的目的是表示一篇文章，而不是处理持久化本身在数据存储中。我强烈建议您查看 Entity Framework 或其他一些用于数据存储的对象/关系映射器。

【参考方案1】：

不知道您的架构名称，但恕我直言，DAL 应该负责持久性，因此直接处理 DB API。

根据我的经验，没有理由认为一些好的做法是矫枉过正的 :) 带有 EF 的通用存储库实现起来非常简单，将来会让您微笑。

【讨论】：

除了存储库，还有其他数据访问模式可以使用吗？

不确定您需要什么。您是否有遗留应用程序或从头开始？可以使用 ORM 吗？