在解决公共课程时注入内部帮助程序课程 [英] Injecting an internal helper class while resolving a public class

查看:98
本文介绍了在解决公共课程时注入内部帮助程序课程的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我具有以下体系结构,其中引用内部Helper类的公共服务类存在于另一个程序集中:

I have the following architecture where a public Service class referencing an internal Helper class exists in another assembly:

ApplicationAssembly {
  public class Widget {
    public Widget(ReferencedAssembly.Service service) { ... }
  }
}

ReferencedAssembly {
  public class Service {
    public Service(Helper helper) { ... }
  }
  class Helper { ... }
}

(我意识到我不能将内部类放在公共类的构造函数的参数中,我只是想说明我要遵循的IoC模式.)

(I realize that I can't put an internal class in the arguments of a public class's constructor--I'm just trying to illustrate the IoC pattern I'm going after.)

问题是 ApplicationAssembly 无法看到 ReferencedAssembly.Helper ,因此无法将其注册到我的IoC容器中(在这种情况下为Autofac).结果,当我尝试解析 Service 时,无法解析 Helper .我在这里最好的选择是什么?

The problem is that ApplicationAssembly can't see ReferencedAssembly.Helper, so it can't be registered in my IoC container (Autofac in this case). As a result, Helper cannot be resolved when I try to resolve Service. What is my best option here?

  • 选项1:从 Service 的构造函数中删除 Helper ,并在构造函数中明确地将其更新.我不喜欢这个选项,因为它打破了IoC范式.

  • Option 1: Remove Helper from Service's constructor and new it up in the constructor explicitly. I don't like this option because it kind of breaks the IoC paradigm.

选项2:使 Helper 实现一个公共的 IHelper 接口,然后在 ReferencedAssembly 中添加一个注册的公共模块.Helper 作为 IHelper .我不喜欢此选项,因为它需要 ApplicationAssembly 来了解关于 Service 的太多实现细节,并且如果用户在启动时忘记注册该模块,一切都会中断.

Option 2: Make Helper implement a public IHelper interface, then add a public module within ReferencedAssembly that registers Helper as an IHelper. I don't like this option because it requires ApplicationAssembly to know too many implementation details about Service, and if the user forgets to register that module at startup everything breaks.

选项3:在 Service 上创建一个公共静态构造函数,该构造函数专门为 ReferencedAssembly 构建第二个IoC容器,并在其中注册 Helper 它.从 Service 的构造函数中删除 Helper ,并使用第二个IoC容器在构造函数中解析它.这似乎是我最好的选择,但是比其他方法需要更多的管道"代码.我也不是公共静态构造函数的忠实拥护者.

Option 3: Create a public static constructor on Service that builds a 2nd IoC container specifically for ReferencedAssembly and registers Helper in it. Remove Helper from Service's constructor and resolve it within the constructor using the 2nd IoC container. This seems like my best option but requires more "plumbing" code than the others. I'm also not a big fan of public static constructors.

选项4.将我的体系结构完全更改为其他内容.

Option 4. Change my architecture to something else altogether.

推荐答案

向Autofac注册内部类型的方法是包括一个Autofac

The way to register internal types with Autofac is to include an Autofac Module inside the assembly with the internal types, and register the module with the container. Because the module is in the same assembly it can configure the ContainerBuilder with the internal types.

我认为最好的选择是使 Service 实现一个公共接口,然后使当前内部具有 Service 类.Autofac会很高兴地实例化一个内部类以提供一个公共接口.

I think the best option is to make Service implement a public interface, then make the Service class that you have currently internal. Autofac will happily instantiate an internal class to provide a public interface.

另一个选择(允许 Service 接受内部类型的构造函数依赖项)是将 Service 的构造函数设置为内部,然后在其中使用构造函数查找器 Service 类型注册:

The other option (to allow Service to take a constructor dependency on an internal type) is to make Service's constructor internal, and then use a constructor finder in the Service type registration:

builder.RegisterType<Service>()
  .FindConstructorsWith(new BindingFlagsConstructorFinder(BindingFlags.NonPublic));

这篇关于在解决公共课程时注入内部帮助程序课程的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆