unit-testing - 存储库模式和工作单元中的架构问题

Question

我已经使用工作单元实现了存储库模式，但存在一些架构问题。

例如，假设我正在创建一个 二手车配件网上商店 .虽然我对我的数据库进行操作，但我也需要对来自不同废料场的远程 API 执行操作，例如需要运行搜索、可用性更新等...

我决定尝试工作单元和存储库模式

做的事情大多像 Mosh Hamedani 但对于 asp.net core 2.1
From videos like this one

只要我使用 EF(或其他与 DB 通信的东西)，工作单元和存储库就可以正常工作并且有意义，但如果我要通过不同的 web api 获取一些数据，那它就没有多大意义。
(例如，从处理和重试相似但不同的不同 API 获取市场上的汽车列表 - 我正在按键检索同一接口(interface)的不同实现)

第一
我不喜欢我的工作单元中所有存储库的所有实例，但在大多数情况下只需要一个。我知道它有助于重用上下文事务而不将其包装在我自己的中，但仍然有不必要的实例很愚蠢。

第二
我应该在存储库和工作单元内实现远程 api 的检索逻辑和处理，还是放弃工作单元并做其他事情？只保留存储库？ (曾经有人提到我不熟悉的外观模式)

我倾向于过度设计事物，现在我很困惑。任何见解都是有帮助的。

Answer 1

虽然我同意 Chris Pratt 的回答，但我认为在某些情况下创建存储库是必要的，即使您使用的是像 EF 这样的 ORM。我已经详细解释了 here .

对于你的问题，我建议你应该继续使用 UoW 和 Repository，就像你目前所做的那样。如前所述here UoW 不仅仅是交易。如果您正确使用 DbContext，EF 会为您完美实现这一点.

关于涉及当前存储库和 UoW 中其他来源的 API 的问题，应该分开。我建议您创建单独的包装器来消耗第三方 API 的复杂性。随心所欲地称呼它；存储库或外部 Api 包装器或其他...