在Service类中继承存储库还是单独关注？

Question

考虑这种依赖注入设置。

  public BookingController(IBookingService bookingService, 
                           IBookingRepository bookingRepository)
  {

  }

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

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

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

分离的优点：

• 以物理方式分离保存和业务逻辑的概念
• 能够切换正在使用的数据层
• 能够通过服务插入对DAL的调用

分离的缺点：

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

您对此有何看法？

Answer 1

这很容易：他们应该保持分离，他们有非常不同的担忧。事实上， BookingService 应该依赖 IBookingRepository 。

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

预订服务关注业务规则，存储库关注持久化实体。您的存储库不应包含任何业务规则，仅包含与持久性相关的详细信息至少在更新模型时。对于查询，直接使用查询处理程序或查询存储库/服务（称之为您想要的）更容易。

Answer 2

另一种看待它的方法：控制器是否应该直接使用不同抽象级别的两个实体（数据访问，业务）？也许控制器中有大量代码使用存储库并执行一些实际上应该是服务中的方法的相关逻辑。不同级别的依赖关系始终是更密切关注代码的标志。有时它没关系，有时候重构是有序的。