【关于具体IOC容器在架构设计中解耦的问题】

[jeremyyang824]

以前设计的时候 系统往往会依赖于具体的IOC容器，不能很好的实现IOC容器与系统的解耦。最近看了NopCommerce和一些其他的开源系统，发现也都与具体的IOC容器有这较强的耦合性。微软的CommonServiceLocator只实现了发现对象的抽象，没有实现注册对象的抽象。
请问有没有例子把IOC容器抽象的比较好的？

[jeremyyang824]

之前我的系统中注册对象的方式和NopCommerce注册的方式类似，都是放到每个组件的实现程序集中，而不是放到启动程序的程序集中统一注册所有组件的依赖关系，这样以便于实现组件的”自注册”
NopCommerce在每个plugin中是通过如下方式实现对象注册的(基于Autofac)：

好处是强类型方便，缺点是每个插件都依赖于Autofac
我之前都是通过文件形式注册的（基于spring.net）：

好处是组件不依赖于IOC容器，缺点是非强类型，注册不方便，容易写错

我现在不想改变这种组件内自注册的方式，但想即使用强类型注册对象又不依赖于具体的IOC容器，所以想抽象IOC的注册方法，以解耦具体IOC容器与具体的组件，有什么好的例子不？

[moonwrite]

不是很明白楼主想要什么~ 我猜楼主说的 不依赖IOC容器是指不依赖具体的IOC组件（也就是不依赖具体的Spring.net还是Autofac）呢~ 还是指不想硬编码而是想通过配置 Autofac也有可以通过配置文件来的 http://www.cnblogs.com/kissdodog/p/3623983.html

[winnowc]

我做过个东西用的是Ninject，也是每个插件要依赖它，当时也有同样的想法，也没找到现成的。 实际上如果有现成的接口帮助隔离，状况也差不多。就好像log框架，插件不需要依赖nlog了，但是还要依赖common.logging。就算能找到现成的比如叫common.ioc，一样是插件不依赖Autofac了，但是还要依赖common.ioc 唯一的区别就是换IoC框架有多大的可能。我认为可能性很低。而且如果使用得当，resolve的接口是统一的，其它地方都没有暴露具体的IoC框架，那就算换也不是很麻烦的事情。所以貌似没人做IoC注册的统一接口，这是个吃力不讨好的事情。

[moonwrite]

但想即使用强类型注册对象又不依赖于具体的IOC容器，所以想抽象IOC的注册方法，以解耦具体IOC容器与具体的组件，有什么好的例子不？ 貌似你要重定义通用接口~ 然后把每个IOC都实现这个接口，有点蛋疼。 而且在属性注入这种方式面前就无能为力了~ 因为每个IOC的属性注入都要加上,Autofac不用加，我最喜欢这点了，虽然从来没有用过属性注入 [xxxxx] //Unity要加 [Dependency]，很多都要加 IService 貌似我一直在提，这是不可能的~ 消极了~

[jeremyyang824]

谢谢楼上几位的回答。
确实我尝试了 发现水瓶不够 工作难度很复杂 比较蛋疼。
另外 我也考虑了 其实换IOC容器的可能性确实不大，只是想有没有这种案例 可以借鉴学习。本人处女座 看着组件依赖于Autofac程序集 有点纠结。

[winnowc]

找了找，还真有人写过。https://github.com/davybrion/Agatha 这里是他定义的公共接口，这里是他Autofac的实现。

[jeremyyang824]

谢谢 热心回答 学习学习。