2022-09-29

DryIoc: register decorator with two interfaces, retrieve the decorator instance when resolving the other interface

Here is a somewhat simplified description of the problem I'm trying to solve: I have a service (e.g. a repository) implementing an interface that I need to inject as a dependency:

public class Service : IService { ... }

I'd like to add a decorator, for example one that add caching that also implements another interface:

public class CachingService: IService, IFlushable
{
  public CachingService(IService decoratee) { ... }

  public void Flush() { ... }
}

public interface IFlushable
{
  public void Flush();
}

Normally, I'd just register the CachingService as an implementation of IService as as decorator, using Setup.Decorator or Setup.DecoratorWith. But in this case I have an extra requirement related to the IFlushable interface. There will be several different services with their own decorators, all of them implementing the both the decorated service interface and IFlushable. I need to inject all the IFlushable decorators as a dependency to be able to flush all the caches on request.

public class CacheHandler
{
  public CacheHandler(IFlushable[] cache) { ... }

  public void FlushAllCaches() { ... }
}

The problem is that this CacheHandler must receive the same decorator instances that were applied to the Service classes.

I have tried several solutions using RegisterMapping and tried to scope the resolution of the caches to their decorated services, but I could not make it work. Either the I receive an error that the container cannot resolve the decorators (which makes sense) or I need to register the decorators themselves, but in the latter case the CacheHandler will receive a new set of IFlushable instances.

The more I think about the more I feel that what I'm trying to achieve here might not even by possible using a DI container. I mean maybe I'm solve this the wrong way. My question is if my approach is valid and/or how can I get all the applied IFLushable decorator instances as a dependency.



No comments:

Post a Comment