继承服务类中的存储库还是其他问题？

Question

考虑此依赖项注入设置。

  public BookingController(IBookingService bookingService, 
                           IBookingRepository bookingRepository)
  {

  }

我的bookingRepository是驻留在数据访问层中的实现，而bookingService是一个bookingService的。 驻留在业务层中。

我使用BookingRepository保存预订，并且我希望预订冲突逻辑在业务层中，因此我有一个预订服务对象。

现在，我有点被撕裂了， IBookingService应该只实现IBookingRepository ，然后继承IBookingRepository类，否则它们应该保持独立。

分离的优点：

• 在物理上将节省的概念与业务逻辑分开
• 能够切换正在使用哪种数据层
• 能够通过服务插入对DAL的呼叫

分离的缺点：

• 我必须在需要它们的地方注入服务和仓库。
• 对服务的许多调用将直接重定向到存储库。

您对此有何想法？

Answer 1

这很简单：他们应该保持隔离，他们有完全不同的关注点。 实际上， BookingService应该依赖IBookingRepository 。

该服务管理预订的用例。 您的控制器仅向服务发送一些输入数据，然后对该服务进行处理（验证业务规则，加载/更新实体等），然后将新的/更新的实体发送到存储库。

Booking Service关心业务规则，Repository关心持久实体。 您的存储库不应包含任何业务规则，而应包含持久性相关的详细信息。 至少在更新模型时。 对于查询，直接使用查询处理程序或查询存储库/服务（将其称为所需内容）会更容易。

Answer 2

看待它的另一种方式：控制器是否应该直接使用处于不同抽象级别（数据访问，业务）的两个实体？ 控制器中可能有很多代码使用存储库，并执行一些实际上应该是服务中方法的相关逻辑。 不同级别的依赖关系始终是更仔细地查看代码的标志。 有时可以，有时可以进行重构。