How to resolve circular dependencies inside of the service layer

Question

I know that others already had this very same issue, but I cannot find any statisfying solution, so I'm asking here for other ideas.

My business logic is contained in a service layer like that:

public class RoomService : IRoomService
{
    private readonly IRoomRepository _roomRepository;
    private readonly ICourseService _courseService;

    public RoomService(IRoomRepository roomRepository, ICourseService courseService)
    {
        _roomRepository = roomRepository ?? throw new ArgumentNullException(nameof(roomRepository));
        _courseService = courseService ?? throw new ArgumentNullException(nameof(courseService));
    }

    public Task DeleteRoomAsync(string id)
    {
        // Check if there are any courses for this room (requires ICourseService)
        // Delete room
    }
}

public class CourseService : ICourseService
{
    private readonly ICourseRepository _courseRepository;
    private readonly IRoomService _roomService;

    public CourseService(ICourseRepository courseRepository, IRoomService roomService)
    {
        _courseRepository = courseRepository ?? throw new ArgumentNullException(nameof(courseRepository));
        _roomService = roomService ?? throw new ArgumentNullException(nameof(roomService));
    }

    public Task GetAllCoursesInBuilding(string buildingId)
    {
        // Query all rooms in building (requires IRoomService)
        // Return all courses for these rooms
    }
}

This is just an example. There might be workarounds to avoid that the services depend on each other in this case, but I had multiple other situations in the past, where there wasn't any clean workaround.

As you can see, these two services depend on each other and dependency injection will fail because of the circular dependency.

Now I can imagine two ways to resolve this:

Solution 1

I could resolve the service-dependencies inside of the service methods that require them instead of injecting the service dependencies into the service constructor:

public class RoomService : IRoomService
{
    private readonly IRoomRepository _roomRepository;
    private readonly IServiceProvider _serviceProvider;

    public RoomService(IRoomRepository roomRepository, IServiceProvider serviceProvider)
    {
        _roomRepository = roomRepository ?? throw new ArgumentNullException(nameof(roomRepository));
        _serviceProvider = serviceProvider ?? throw new ArgumentNullException(nameof(serviceProvider));
    }

    public Task DeleteRoomAsync(string id)
    {
        ICourseService courseService = _serviceProvider.GetRequiredService<ICourseService>();

        // Check if there are any courses for this room (requires ICourseService)
        // Delete room
    }
}

Problem: This makes unit testing harder because I need to inject a mocked IServiceProvider that is able to resolve my ICourseService into the class constructor. Also it's not very clear when writing the unit tests, which services are required by each service method because that's completely implementation dependant.

Solution 2

The service method could require that the ICourseService is passed in from the controller as a method parameter:

public Task DeleteRoomAsync(ICourseService courseService, string id)
{
    // Check if there are any courses for this room (requires ICourseService)
    // Delete room
}

Problem: Now my controller needs to know about an implementation detail of the service method: DeleteRoomAsync requires an ICourseService object to do it's work. I think that's not very clean because the requirements of DeleteRoomAsync might change in future, but the method signature should not.

Can you think of any alternative, cleaner solutions?

Answer 1

If your framework supports it, you can provide your injected dependencies as a Lazy<T> which defers resolution and allows you to have circular dependencies.

Here's what those service classes might look like:

class FooService : IFooService
{
    protected Lazy<IBarService> _bar;

    public FooService(Lazy<IBarService> bar)
    {
        _bar = bar;
    }

    public void DoSomething(bool callOtherService)
    {
        Console.WriteLine("Hello world. I am Foo.");
        if (callOtherService)
        {
            _bar.Value.DoSomethingElse(false);
        }
    }

}

class BarService : IBarService
{
    protected Lazy<IFooService> _foo;

    public BarService(Lazy<IFooService> foo)
    {
        _foo = foo;
    }
    public void DoSomethingElse(bool callOtherService)
    {
        Console.WriteLine("Hello world. I am Bar.");
        if (callOtherService)
        {
            _foo.Value.DoSomething(false);
        }
    }
}

The code that registers them does not require modification (at least not with Autofac):

public static IContainer CompositionRoot()
{
    var builder = new ContainerBuilder();
    builder.RegisterType<FooService>().As<IFooService>().SingleInstance();
    builder.RegisterType<BarService>().As<IBarService>().SingleInstance();
    builder.RegisterType<Application>().SingleInstance();
    return builder.Build();
}

See a working example on DotNetFiddle.

If your framework does not support lazy injection like this, you can probably do the exact same thing using a factory (or any other pattern that defers resolution).

See also this answer which helped me come up with this solution.

Answer 2

The best solution is to avoid circular dependencies, of course, but it you're truly stuck, you can work around the issue by using property injection and RegisterInstance<T>(T t) (or its equivalent, if you're not using Autofac).

For example, if you have a FooService class and a BarService class that depend on each other, you can do this:

public static IContainer CompositionRoot()
{
    var foo = new FooService();
    var bar = new BarService();
    foo.Bar = bar;
    bar.Foo = foo;

    var builder = new ContainerBuilder();
    builder.RegisterInstance<IFooService>( foo );
    builder.RegisterInstance<IBarService>( bar );
    builder.RegisterType<Application>().SingleInstance();
    return builder.Build();
}

This instantiates both services without their dependencies, and then sets them to each other afterward. By the time they are registered with the IoC container, their dependencies are completely set up.

See my Fiddle for a working example.

Answer 3

In provided examples, I would re-consider if you really have inter-service dependencies in those kind of situations:

• Do you need logic contained in ICourseService in your RoomService implementation, or do you only need information from certain courses?

  I would say that the latter one, so your real dependency could be ICourseRepository with a method ICourseRepository.FindByRoom(Room room).

• Do you need logic contained in IRoomService in your CourseService implementation, or do you only need existing rooms?

  In this case, IRoomRepository could be enough.

However, it isn't always that easy and sometimes you really require logic implemented in Service layer, (validations, etc.). Trying to extract that behavior to shared classes rather than duplicating it or creating circular dependencies as mentioned can be preferrable in those scenarios.