c# - 具有使用 IoC 容器的重载方法

标签 c# dependency-injection inversion-of-control

我在 COM 对象之上编写 API,您必须将 COM 对象传递到我编写的几乎所有类型和静态方法中,以便我可以测试 API 的每个部分。

现在我的问题是,我是否有一个重载方法用于获取 COM 对象但将 IoC 解析的一个而不是另一个传递给另一个,这样 API 的用户就不必担心传入COM 对象还是我应该删除重载方法并只解析它而不选择传递它。

有点难以解释,所以这里是一个例子;

构造函数示例;

FooType(IComObject obj,string table) {}
FooType(string table) : this(Ioc.Resolve<IComObject>(), table) {}

或者只是

FooType(string table) : this(Ioc.Resolve<IComObject>(), table) {}

静态方法示例;

public static SomeType Create(IComObject obj,string table) 
{ // Do some work with obj}

public static SomeType Create(string table) 
{ 
   return MyClass.Create(Ioc.Resolve<IComObject>(),table);
}

或者只是

public static SomeType Create(string table) 
{ 
   IComObject obj = Ioc.Resolve<IComObject>();
   return MyClass.Create(Ioc.Resolve<IComObject>(),table);
}

我对重载最大的担心是它会创建很多只会向后调用的方法。我在这里还有什么其他选择,或者这是解决这个问题的正确方法吗?

P.S 我真的不想让用户负担必须在他们的应用程序周围传递 IComObject 实例的负担。

最佳答案

依赖注入(inject)的原则之一是类的依赖应该对外界明确。当一个类自己解决依赖关系时(如在您的第二个示例中),它违反了该原则,并且回到了使用单例服务的道路上-尽管诚然,您的情况要好一些,因为您确实将 IoC 容器作为“逃生” hatch"用于模拟服务对象。

显然,在所有对象的构造函数中加载一大堆参数是相当麻烦的,但这正是 IoC 容器介入的地方。如果它支持 Autowiring ,并且您按设计使用它,您通常发现自己不得不自己解决很少的实例:你拉出第一个对象,它已经准备好配置所有依赖项——它们已经准备好配置所有依赖项,等等。为此,约书亚·弗拉纳根 makes the argument IoC Containers 真的应该被称为 IoC Composer。

如果您想避免给您的 API 用户带来负担,如何使用一个焦点对象来包装您的 IoC 容器并从中拉出配置的实例以供调用代码使用?

关于c# - 具有使用 IoC 容器的重载方法,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/948959/

相关文章:

c# - 压缩 SQL Server 2005 查询结果?

c# - C# .Net 2.0 是否有基于规范的测试框架?

c# - 如何删除DataTable中的行

c# - AddSingleton - 生命周期 - 类是否需要实现 IDisposable?

wcf - 将 IoC 支持添加到 Windows 服务中托管的 WCF 服务 (Autofac)

architecture - DIP vs. DI vs. IoC

c# - 如何使用 DateTime 类测量耗时?

c# - 多线程应用程序中基于上下文的依赖注入(inject)

unit-testing - 具有提供者依赖性的 Angular2 测试组件

c# - 如何构造函数注入(inject)仅在运行时已知的字符串? (温莎城堡)