Inheriting Repository in Service class or Seperate Concerns?

Question

Consider this Dependency Injection Setup.

  public BookingController(IBookingService bookingService, 
                           IBookingRepository bookingRepository)
  {

  }

My bookingRepository is an implementation residing in the Data Access Layer, and bookingService is an impl. residing in the Business Layer.

I use BookingRepository to save booking, and I want the Booking conflict logic to be in the business layer, hence I have a booking service object.

Now I'm a little torn wether IBookingService should just implement the IBookingRepository and then inherit the BookingRepository class, or they should stay seperate.

Pros of seperation:

• Physically seperating the concept of saving and the business logic
• Being able to switch what kind of datalayer is being used
• Being able to interject calls to the DAL through the service

Cons of seperation:

• I have to inject both the service and the repo everywhere I need them both.
• Many calls to the service, will just be redirected directly to the repository.

What are your thoughts on this?

Answer 1

That's an easy one: they should stay separated, they have very different concerns. In fact the BookingService should take a dependency on IBookingRepository .

The service manages the use case of a booking. Your controller just sends some input data tot the service, which process it (verify business rules, loads/update entities etc) then sends the new/updated entities to the repository.

Booking Service cares about business rules, Repository cares about persisting entities. Your repository should not contain any business rules, only persistence related details. At least when updating models. For querying, it's easier to use directly a query handler or a query repository/service (call it what you want).

Answer 2

Another way to look at it: Should the controller be directly using two entities at different levels of abstraction (data access, business)? Perhaps there are chunks of code in the controller that use the repository and do some related logic that should actually be methods in the service. Dependencies at different levels is always a flag to look more closely at the code. Sometimes it's OK and sometimes refactoring is in order.