存储库模式和工作单元中的体系结构问题

Question

我已经用工作单元实现了存储库模式，但是有一些体系结构问题。

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

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

大多数事情像Mosh Hamedani一样，但是对于asp.net core 2.1 From videos like this one

只要我使用EF（或与DB进行其他通信），工作单元和存储库就可以正常工作，并且有意义，但是如果我要通过不同的Web API获取一些数据就没有多大意义了。 （例如，从不同的API获取市场上的汽车清单，这些API的处理和重试是相似的，但有所不同-我通过密钥检索同一接口的不同实现）

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

第二 我是否还应该在存储库和工作单元中或者在工作单元中放弃远程api的检索逻辑和处理，还是做其他事情？仅保留存储库？ （有人曾经提到我不熟悉的门面图案）

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

Answer 1

存储库模式仅用于一个目的：从应用程序代码中提取SQL。存在工作单元模式只是为了支持和协调具有多个存储库的事务操作。 EF和其他ORM为您处理所有这一切。特别是对于EF，每个DbSet是一个存储库，DbContext是工作单元。当您使用像EF这样的ORM时，那个是您的数据层，而不是您传统上可能创建的某些自定义类库。您绝对应该不要在诸如EF之类的东西上实现工作模式的存储库/单元。

您正在寻找的实质上是一个API网关。在微服务体系结构中，每个服务都处理一个离散的功能单元，这意味着使用许多（如果不是全部）这些微服务的跨领域应用程序将具有非常可观的依赖关系。最典型的方法是创建一个或多个API网关，这些网关实质上打包了与所有或特定的微服务子集的通信。您的应用程序仅直接与API网关通信，并且API网关协调与所有微服务之间的通信，以促进应用程序的请求。这进一步使您可以无缝地实现诸如消息队列之类的层。

Answer 2

尽管我同意克里斯·普拉特（Chris Pratt）的回答，但我认为即使在使用诸如EF之类的ORM的情况下，还是有必要创建存储库。我已经详细说明了here。

关于您的问题，我建议您到目前为止应该继续使用UoW和存储库。如前所述，here不仅仅是交易。如果您正确使用data.sql，EF会为您完美实现。

关于涉及当前存储库和UoW中其他来源的API的问题，应将其分开。我建议您创建单独的包装，以消耗第三方API的复杂性。随便你叫什么；存储库或外部Api包装器或其他任何内容...

Answer 3

我使用相同的课程并实现了我的工作单元……但是后来，我改变了主意，取消了UoW类。 DbContext已在实现UoW和存储库模式：From MS Documentation

  

DbContext类

     

代表工作单元和存储库模式的组合   并允许您查询数据库并将更改分组在一起   然后将其作为一个单元写回到商店。 DbContext是   在概念上类似于ObjectContext。

我仍然添加了自己的存储库。我同意克里斯的观点，DbSet是一个存储库，但是我可以通过添加自己的存储库来添加更多专门的方法。

在您链接的视频中，我们通过将所有存储库放在UoW类中来实现UoW。我认为此实现可能违反某些SOLID原则：

1. 感觉就像在违反开放式/封闭式原则...，因为每次添加新的存储库时，我们都需要修改UoW类以包括新的存储库。
2. 感觉就像我们在违反接口隔离原则。 ISP指出，不应强迫客户端实施不使用的接口。 UoW包含所有存储库的实现...但是，使用方客户端不需要所有这些实现，客户端可能只需要其中一个即可。
3. 感觉像我们违反了单一责任原则，因为UoW负责这么多存储库。