My.Ioc 是作者开发的一款开源 IoC/DI 框架，下载地址在此处。它具有下面一些特点：

高效

在实现手段上，My.Ioc 通过使用泛型、缓存、动态生成代码、延迟注册、尽量使用抽象类而非接口等方式来提高框架的性能。如果您想进一步了解通过上面这些手段，我们能够获得怎样的性能，请看这篇文章。

便于扩展

在设计时，可扩展性是作者始终关注的问题之一。My.Ioc 也确实提供了良好的可扩展性。您可以通过以下方式实现扩展：

1. 自定义 Lifetime 实现。

2. 注册自定义 ObjectBuilderRequested 事件 Handler 以实现延迟注册（参见这篇文章）。

3. 通过添加自定义 IConstructorInjectionConfigurationItem/IMemberInjectionConfigurationItem 以及修改现有 IInjectionConfigurationInterpreter 的方式增加或修改对象创建逻辑（参见这篇文章）。例如，要想给某个现有注册项增加 Decorator，可以通过增加一个 IConstructorInjectionConfigurationItem 的方式来实现。

配置简单

使用代码方式进行注册，而不必编写一大堆配置文件那么繁琐。当然，配置方式是可以扩展的，而且也很容易扩展。如果您喜欢，您也可以自行实现一个通过配置文件进行注册的机制。

功能全面

• 支持构造函数、属性和方法注入（参见这篇文章和这篇文章）。
• 采用 Fluent Api 方式进行配置。
• 自动注册/解析未注册的类型（必须是具体类型，而不能是接口、抽象类或值类型。参见这篇文章）。
• 支持 Open Generic 类型注册。
• 支持延迟注册（参见这篇文章）。
• 良好的可扩展性（参见这篇文章）。
• 默认提供 Container/Scope/Transient 三种 Lifetime，但允许自定义 Lifetime。
• 支持元数据（参见这篇文章）。
• 支持条件绑定（或称上下文绑定。例如，如果有多个类（使用者）都需要依赖于 IMyService 服务，那么使用者在注册不同 IMyService 实现时，可以指定只有满足某些条件的使用者才能使用该实现。参见这篇文章）。
• 支持依赖对象映射（例如，某个类的构造函数需要依赖于一个 IEnumerable<IMyService> 对象，而 IEnumerable<IMyService> 未注册，但容器中注册了 IMyService 的一个或多个实现，此时可通过对象映射器 [ObjectMapper] 将这些实现组装成一个 IEnumerable<IMyService> 对象以满足构造需要）。
• 支持注销对象（参见这篇文章）。
• 提供 IObjectObserver/IObjectCollectionObserver 机制，可以在所依赖的对象注册/注销/激活/停用时收到事件通知，从而更好地响应变化（参见这篇文章）。
• 支持 .net 2.0。

面向服务考虑

在面向服务环境中，服务经常处于变化之中。一个服务可能在这一时刻可用，但下一时刻已不可用。为此，框架提供了注销 (Unregister) 功能和观察者 (IObjectObserver/IObjectCollectionObserver) 机制来适应这种变化。使用者可以在运行过程中随时注销某个服务实现（前提是该实现由该使用者注册，而且该使用者在注册服务时保留了该服务的 IObjectRegistration 对象）或注册新的服务实现以替代已被注销/过期 (Obsolete) 的服务实现，而其他依赖于该服务的上层服务将会随着该服务的注销/注册而自动停用/激活，相关的观察者则会向自身的 Changed 事件订阅者发送服务激活 (Activated)/停用 (Deactivated) 的通知。

富于交互性

框架提供了 ObjectBuilderRegistered/ObjectBuilderUnregistering/ObjectBuilderRequested 事件、IObjectObserver/IObjectCollectionObserver 的通知事件、ILifetimeScope 的 LifetimeScopeEnded 事件（可用于在资源释放后执行自定义操作）、IObjectRegistration 的 Changed 事件等各类事件，使用者可以根据需要订阅它们，以实现与框架的交互。

安全性

安全性是作者在设计时的重要考量之一。框架具备线程安全性，可用于多线程环境中。此外，框架通过 ILifetimeScope 来管理资源的释放 (Dispose)。使用者在解析（获取）对象/服务时，必须指定相应的 ILifetimeScope，并在使用完成后正确释放 ILifetimeScope，从而确保资源安全性。最后，框架遵循最小可访问性原则（尽量使用 private、protected、internal，少用 public），以保证良好的封装和可见性控制，从而防止 Api 滥用或误用。

零侵入性

同安全性一样，侵入性也是作者在设计时的考量之一。因此，我们摒弃了其他一些 Ioc 框架（例如 NInject/Unity）所采用的通过 Attribute 标注实现某些功能的方式（例如标注某个要注入的构造函数/属性/方法等），转而要求使用者在注册时提供具体信息（例如在配置方法注入时，只需提供方法名称即可。但如果该方法含有多个重载，则需提供具体的 MethodInfo），以保证框架的零侵入性。