在阅读了越来越多有关 IoC 容器的信息后，我阅读了 this post 关于在您的代码中没有 IoC.Resolve() 等。
我真的很想知道，我怎样才能去除对容器的依赖？
我想编写如下代码：
public void Action()
{
using(IDataContext dc = IoC.Resolve<IDataContext>())
{
IUserRepository repo = IoC.Resolve<IUserRepository>();
// Do stuff with repo...
}
}
但是我怎样才能摆脱 IoC.Resolve 调用呢？也许我需要更好地了解 DI...
提前致谢。
【问题讨论】：
标签： c# dependency-injection inversion-of-control ioc-container
一般来说，大多数依赖项都可以在创建类时注入到您的类中。但是，在这种特殊情况下，您需要一个必须在使用时按需创建的组件。在这种情况下，很难完全消除对 IoC 容器的依赖。我的方法一直是创建一个在创建时注入到类中的工厂，这反过来又封装了所有直接的 IoC 使用。这允许模拟您的工厂进行测试，而不是模拟 IoC 容器本身......这往往要容易得多：
// In Presentation.csproj
class PresentationController
{
public PresentationController(IDataContextFactory dataContextFactory, IRepositoryFactory repositoryFactory)
{
#region .NET 4 Contract
Contract.Requires(dataContextFactory != null);
Contract.Requires(repositoryFactory != null);
#endregion
_dataContextFactory = dataContextFactory;
_repositoryFactory = repositoryFactory;
}
private readonly IDataContextFactory _dataContextFactory;
private readonly IRepositoryFactory _repositoryFactory;
public void Action()
{
using (IDataContext dc = _dataContextFactory.CreateInstance())
{
var repo = _repositoryFactory.CreateUserRepository();
// do stuff with repo...
}
}
}
// In Factories.API.csproj
interface IDataContextFactory
{
IDataContext CreateInstance();
}
interface IRepositoryFactory
{
IUserRepository CreateUserRepository();
IAddressRepository CreateAddressRepository();
// etc.
}
// In Factories.Impl.csproj
class DataContextFactory: IDataContextFactory
{
public IDataContext CreateInstance()
{
var context = IoC.Resolve<IDataContext>();
// Do any common setup or initialization that may be required on 'context'
return context;
}
}
class RepositoryFactory: IRepositoryFactory
{
public IUserRepository CreateUserRepository()
{
var repo = IoC.Resolve<IUserRepository>();
// Do any common setup or initialization that may be required on 'repo'
return repo;
}
public IAddressRepository CreateAddressRepository()
{
var repo = IoC.Resolve<IAddressRepository>();
// Do any common setup or initialization that may be required on 'repo'
return repo;
}
// etc.
}
这种方法的好处是，虽然您不能完全消除 IoC 依赖本身，但您可以将其封装在一种对象（工厂）中，从而将大部分代码与 IoC 容器解耦。鉴于从一个 IoC 容器切换到另一个（即 Windsor 到 Ninject），这提高了您的代码敏捷性。
应该注意，这样做的一个有趣结果是，您的工厂通常由它们使用的相同 IoC 框架注入到它们的依赖项中。例如，如果您使用 Castle Windsor，您将创建配置，告诉 IoC 容器在创建时将两个工厂注入到您的业务组件中。业务组件本身也可能有一个工厂……或者，它可以简单地由同一个 IoC 框架注入到更高级别的组件中，等等，ad inf。
【讨论】：
using 语句。然后，如果我 Resolve 说IDataContext，它将为该特定范围解析 single instance。我不希望我的控制器等知道 IoC 容器，但真的有办法解决这个问题吗？
另一种方法是重写方法以接受Func<T> 委托。这从方法中删除了依赖关系，并允许您使用模拟对其进行单元测试：
public void Action(Func<IDataContext> getDataContext, Func<IUserRepository> getUserRepository)
{
using(IDataContext dc = getDataContext())
{
IUserRepository repo = getUserRepository();
// Do stuff with repo...
}
}
【讨论】：
不久前，我参与了一个尚未确定 IoC 容器的项目。他们通过禁止容器的非 IoC 特定功能以及用自己的类包装 Resolve 来管理不确定性。这也是我在博文中看到过几次提倡的……删除最后一个依赖，对依赖注入容器的依赖。
这是一种可行的技术，但在某些时候，您必须选择您使用的工具，并愿意接受您为切换到替代工具而付出的代价。对我来说，IoC 容器属于你可能应该全心全意拥抱的东西，所以我质疑这种级别的分解。如果您想进一步研究，我建议以下链接：
http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion
【讨论】：
我最近写了一篇关于这个问题的博客：
【讨论】：
有第二个依赖注入器来注入第一个，并让第一个注入第二个。
【讨论】：