我使用了Repository pattern和Unit of work来实现项目,但还存在一些架构问题。
比如说,假设我正在创建一个二手汽车零件在线商店。虽然我有对我的数据库的操作,但我也需要从不同的废料场执行对远程API的操作,例如需要运行搜索、可用性更新等等...
我决定尝试使用unit of work和repository pattern
大多数事情都像Mosh Hamedani所做的那样,但是针对asp.net core 2.1进行了调整 就像这个视频
只要我使用EF(或者其他与数据库通信的工具),Unit of work和repositories都可以正常工作并且很合理,但如果我需要通过不同的Web API获取一些数据,则这种模式就没有太多意义了。 (例如从不同的API获取市场上的汽车列表,它们的处理和检索方式相似但略有不同-我通过密钥检索到相同接口的不同实现)。
首先 我不喜欢在我的unit of work中拥有所有repositories的所有实例,但是在大多数情况下只需要一个。我知道这有助于重复使用上下文事务而不将其包装在自己的事务中,但仍然很愚蠢,因为它会产生不必要的实例。
其次 我应该在repository和unit of work中也实现远程API的检索逻辑和处理,还是放弃unit of work并做其他事情?只保留repositories?(有人曾提到我不熟悉的facade pattern)
我往往会过度工程化,现在我非常困惑。任何建议都有帮助。
DbContext/DbSet
。 - Fabio