存储库模式实施建议

Question

我正在现有系统上实现存储库模式，主要是为了能够对我的业务逻辑层进行单独的单元测试。但我担心我的层太多，建议将不胜感激。没有 ORM，使用 SQL Server 作为数据库。

我有以下几点：

1. DataMapping 层 - 将对象链接到数据库表
2. 存储库接口
3. 存储库具体实现
4. 业务逻辑层
5. 表示层

我发现我经常在 Repository Concrete Implementation 中创建一个方法，该方法返回一段简单的数据（例如 Expiry Date - DateTime 变量），然后将运行 Repository Concrete 的业务逻辑层方法放在一起实现方法并将其返回给表示层。

如果 BLL 没有添加任何额外的逻辑，那么 Presentation Later 是否可以直接调用具体实现方法？并且只有在单元测试有附加逻辑时才使用 BLL 方法？

我正在使用依赖注入来管理具体的实施。

谢谢。

Answer 1

在我看来，您误解了存储库模式的目的。这个想法是创建一个类，它允许您集中管理特定模型的所有存储/检索 - 使用它返回像 DateTime 这样的简单类型似乎是错误的方法。

你的存储库应该纯粹处理对象，所以你会有类似的方法

SomeClass GetSomeClass(...);
void AddSomeClass(...);

没有

DateTime GetExpiryDate(...);
string GetName(...);

分层架构的重点是确保您不会耦合应用程序的各个部分

• DAL 不应该知道 BLL/PL
• BLL 应该了解 DAL，但应该通过您的存储库进行控制
• PL 应该知道 BL，但应该通过服务控制（通常）

在层之间进行通信时，通常认为使用接口而不是具体类是一个好主意。接口定义了一个合约，然后您可以围绕该合约对各自的层进行建模 - 想法是您隐藏了实现，因此如果您将来完全更改它，其他层将不知道。

例如，如果您的 BLL 通过IRepository 接口与 DAL 通信，则 BLL 只能在该接口的范围内工作，它不知道 DAL 使用哪种存储机制 - 这被称为坚持无知。因此，如果将来您将 DAL 从 MS SQL 后端换成 MySQL 后端，这对您的 BLL 没有影响，因为层之间的合同（即IRepository 接口）没有改变。

Answer 2

使用存储库模式不取决于您是否使用 ORM，您可以简单地在存储库库中使用经典的 Ado.net。但关于分层应用程序，我建议您查看 this 博客文章

如果 BLL 没有添加任何额外的逻辑，Presentation later 是否有直接调用具体实现方法的情况？ 确定如果您没有任何 BLL 或服务层 imp，您可以稍后在您的演示文稿中直接调用存储库。

参考this文章正确实现repository