一个快速总结(这个主题有更多的阅读,我强烈建议阅读更多)…

Microsoft企业模式和实践团队的Unity是一个控制反转容器项目,简称IoC.就像Castle Windsor,StructureMap等一样.这种类型的开发在lamen的术语中也被称为Loosely Coupling your components.

IoC包含对象的依赖注入模式,您可以依赖外部组件来连接对象中的依赖项.

例如,您不是访问静态管理器(几乎不可能进行单元测试),而是创建一个依赖于外部依赖关系来操作的对象.让我们选择一个Post服务,您可以在其中访问数据库以获取帖子.

public class PostService : IPostService
{
  private IPostRepository _postRepo;

  public PostService(IPostRepository postRepo)
  {
    _postRepo = postRepo;
  }

  public IList<Post> GetPosts()
  {
    return _postRepo.GetAllPosts().ToList();
  }
}

此PostService对象现在具有对IPostRepository的外部依赖性.请注意如何使用没有混凝土和静态管理器类？相反,您有一个简单接口的松散耦合 – 这使您能够连接实现IPostRepository的所有不同类型的具体类.

Microsoft Unity的目的是自动为您连接该IPostRepository.所以你永远不必担心这样做：

// you never have to do this with Unity
IPostRepository repo = new PostRepository();
IPostService service = new PostService(repo); // dependency injection
IList<Post> posts = service.GetPosts();

上面显示了你必须实现两个具体类,PostRepository()和PostService().这是将您的应用程序紧密耦合到需求/需要这些精确实例,并使单元测试非常困难.

相反,您将在终点使用Unity(MVC中的控制器,或ASPX页面中的代码)：

IUnityContainer ioc = new UnityContainer();
IPostService postService = ioc.Resolve<IPostService>();
IList<Post> posts = postService.GetPosts();

请注意,此示例中没有使用混凝土(显然除了UnityContainer和Post)！没有服务的混凝土,也没有存储库.这是最好的松散耦合.

这是真正的踢球者……

Unity(或任何IoC容器框架！)将检查IPostService的任何依赖性.它会看到它(希望)依赖于IPostRepository的实例.因此,Unity将进入它的对象映射并查找实现向容器注册的IPostRepository的第一个对象,并返回它(即sqlPostRepository实例).这就是IoC框架背后的真正力量 – 检查服务并自动连接任何依赖关系的能力.

我需要完成关于UNity vs Castle vs StructureMap比较的博客文章.我实际上更喜欢Castle Windsor,因为它的配置文件选项和个人的可扩展性点.