在使用依赖注入(inject)时，我在装饰器模式的实现中遇到了 StackoverflowException。我认为这是因为我对 DI/IoC 的理解“遗漏”了一些东西。

例如，我目前有 CustomerService 和 CustomerServiceLoggingDecorator。这两个类都实现了 ICustomerService，装饰器类所做的只是使用注入(inject)的 ICustomerService 但添加了一些简单的 NLog 日志记录，这样我就可以在不影响 中的代码的情况下使用日志记录CustomerService 同时也不违反单一职责原则。

但是这里的问题是，因为 CustomerServiceLoggingDecorator 实现了 ICustomerService，它还需要注入(inject) ICustomerService 的实现才能工作，Unity将继续尝试将其解析回自身，这会导致无限循环，直到它溢出堆栈。

这些是我的服务:

public interface ICustomerService
{
    IEnumerable<Customer> GetAllCustomers();
}

public class CustomerService : ICustomerService
{
    private readonly IGenericRepository<Customer> _customerRepository;

    public CustomerService(IGenericRepository<Customer> customerRepository)
    {
        if (customerRepository == null)
        {
            throw new ArgumentNullException(nameof(customerRepository));
        }

        _customerRepository = customerRepository;
    }

    public IEnumerable<Customer> GetAllCustomers()
    {
        return _customerRepository.SelectAll();
    }
}

public class CustomerServiceLoggingDecorator : ICustomerService
{
    private readonly ICustomerService _customerService;
    private readonly ILogger _log = LogManager.GetCurrentClassLogger();

    public CustomerServiceLoggingDecorator(ICustomerService customerService)
    {
        _customerService = customerService;
    }

    public IEnumerable<Customer> GetAllCustomers()
    {
        var stopwatch = Stopwatch.StartNew();
        var result =  _customerService.GetAllCustomers();

        stopwatch.Stop();

        _log.Trace("Querying for all customers took: {0}ms", stopwatch.Elapsed.TotalMilliseconds);
        return result;
    }
}

我目前有这样的注册设置(这个 stub 方法是由 Unity.Mvc 创建的):

        public static void RegisterTypes(IUnityContainer container)
        {
            // NOTE: To load from web.config uncomment the line below. Make sure to add a Microsoft.Practices.Unity.Configuration to the using statements.
            // container.LoadConfiguration();

            // TODO: Register your types here
            // container.RegisterType<IProductRepository, ProductRepository>();

            // Register the database context
            container.RegisterType<DbContext, CustomerDbContext>();

            // Register the repositories
            container.RegisterType<IGenericRepository<Customer>, GenericRepository<Customer>>();

            // Register the services

            // Register logging decorators
            // This way "works"*
            container.RegisterType<ICustomerService, CustomerServiceLoggingDecorator>(
            new InjectionConstructor(
                new CustomerService(
                    new GenericRepository<Customer>(
                        new CustomerDbContext()))));

            // This way seems more natural for DI but overflows the stack
            container.RegisterType<ICustomerService, CustomerServiceLoggingDecorator>();

        }

所以现在我不确定实际创建具有依赖注入(inject)的装饰器的“正确”方法。我的装饰器基于 Mark Seemann 的回答 here .在他的示例中，他正在更新几个传递到类中的对象。这就是我的它“工作”* 片段的工作方式。但是，我认为我错过了一个基本步骤。

为什么要像这样手动创建新对象？这是否否定了让容器为我解析的意义？或者我应该在这个方法中执行 contain.Resolve()(服务定位器)，以获取仍然注入(inject)的所有依赖项？

我对“复合根”概念略微熟悉，您应该将这些依赖项连接到一个且仅一个位置，然后向下级联到应用程序的较低级别。那么 Unity.Mvc 生成的 RegisterTypes() 是 ASP.NET MVC 应用程序的组合根吗？如果是这样，直接在此处更新对象实际上是正确的吗？

我的印象是，通常使用 Unity 您需要自己创建组合根，但是，Unity.Mvc 是一个异常(exception)，因为它创建了自己的组合根，因为它似乎能够在构造函数中将依赖项注入(inject)到具有接口(interface)(例如 ICustomerService)的 Controller 中，而无需我编写代码来实现这一点。

问题:我认为我遗漏了一条关键信息，由于循环依赖，这导致我出现StackoverflowExceptions。如何在仍然遵循依赖注入(inject)/控制反转原则和约定的同时正确实现我的装饰器类？

第二个问题:如果我决定只想在某些情况下应用日志装饰器呢？因此，如果我有 MyController1，我希望有一个 CustomerServiceLoggingDecorator 依赖项，但是 MyController2 只需要一个普通的 CustomerService，如何创建两个单独的注册？因为如果我这样做:

container.RegisterType<ICustomerService, CustomerServiceLoggingDecorator>();
container.RegisterType<ICustomerService, CustomerService>();

然后一个将被覆盖，这意味着两个 Controller 都将注入(inject)装饰器或注入(inject)普通服务。我如何允许两者兼顾？

编辑:这不是一个重复的问题，因为我在循环依赖方面遇到了问题，并且对此缺乏正确的 DI 方法的理解。我的问题适用于整个概念，而不仅仅是像链接问题那样的装饰器模式。

最佳答案

序言

每当您在使用 DI 容器(Unity 或其他)时遇到问题，问问自己:is using a DI Container worth the effort?

在大多数情况下，答案应该是否。使用 Pure DI反而。用 Pure DI 回答你所有的答案都是微不足道的。

团结

如果您必须使用 Unity，也许以下内容会对您有所帮助。自 2011 年以来我就没有使用过 Unity，所以从那以后情况可能发生了变化，但在 my book 的第 14.3.3 节中查找问题。 ，这样的事情可能会成功:

container.RegisterType<ICustomerService, CustomerService>("custSvc");
container.RegisterType<ICustomerService, CustomerServiceLoggingDecorator>(
    new InjectionConstructor(
        new ResolvedParameter<ICustomerService>("custSvc")));

或者，您也可以这样做:

container.RegisterType<ICustomerService, CustomerServiceLoggingDecorator>(
    new InjectionConstructor(
        new ResolvedParameter<CustomerService>()));

此替代方案更易于维护，因为它不依赖命名服务，但具有(潜在的)缺点，即您无法通过 ICustomerService 接口(interface)解析 CustomerService .无论如何你可能不应该这样做，所以这应该不是问题，所以这可能是一个更好的选择。

关于c# - 依赖注入(inject)组合根和装饰器模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36048646/