在UnityContainer中删除已注册的类型,可以使用以下方法:
container.Unregister<T>();
其中,T 是要删除的类型。
T
例如,如果要从UnityContainer中删除已注册的IFoo 类型,可以使用以下代码:
IFoo
container.Unregister<IFoo>();
需要注意的是,在删除已注册的类型时,需要确保该类型没有被其他类型依赖,否则删除操作可能会导致其他类型的注册失效。
Unity是微软P&P部门开发的一个轻量级IoC框架,通过Interception机制可以实现基于三种拦截机制的AOP。不过Unity仅仅提供“显式”拦截机制,以致我们为了注册可被拦截的类型会多写很多代码和配置。本篇文章通过UnityContainer的扩展提供了一种“自动”拦截机制。 一、显式拦截 我们通过一个简单的实例演示Unity原生支持的显式拦截机制和我们通过扩展实现的自动拦截机制。我们定了如下一个简单的SimpleCallHandler,在Invoke方法中通过在控制台打印一段文字用以证明应用在某
对EnterLib有所了解的人应该知道,其中有一个名叫Policy Injection的AOP框架;而整个EnterLib完全建立在另一个叫作Unity的底层框架之上,我们可以将Unity看成是一个IoC的框架。对于一个企业应用来说说,AOP和IoC是我们进行逻辑分离和降低耦合度最主要的方式,而将两者结合起来具有重要的现实意义。 一、基于IoC+AOP的编程 到底将IoC和AOP进行整合后,会对编程但来怎样的影响,我写了一个简单的例子(你可以从这里下载该实例)。假设我现在有两个模块,分别称为Foo和Bar,
在《这是EnterLib PIAB的BUG吗?》一文中我们讨论了PIAB关于抽象基类的BUG,今天又发现了一个新的问题。问题的起因源于《IoC+AOP的简单实现》这篇文章,因为文中给出的解决方案仅仅支持构造器注入(Constructor Injection),而不能支持属性注入(Property Injection)和方法注入(Method Injection)。这是由于EnterLib的PIAB设计本身就存在缺陷。 对EnterLib 5.0有一定了解的人都应该知道,在新版本的EnterLib中,原来的O
关于Ioc的框架有很多,比如astle Windsor、Unity、Spring.NET、StructureMap,我们这边使用微软提供的Unity做示例,你可以使用Nuget添加Unity,也可以引用Microsoft.Practices.Unity.dll和Microsoft.Practices.Unity.Configuration.dll,下面我们就一步一步的学习下Unity依赖注入的详细使用。如果不明白什么是控制反转和依赖注入,请参考控制反转和依赖注入模式 下面通过一个示例来讲解Unity不同的依
源码路径:Github-EventBus 事件总线知多少(1) 事件总线知多少(2) 1.引言 之前的一篇文章事件总线知多少(1),介绍了什么是事件总线,并通过发布订阅模式一步一步的分析重构,形
毫不夸张地说,整个ASP.NET Core框架是建立在一个依赖注入框架之上的,它在应用启动时构建请求处理管道过程中,以及利用该管道处理每个请求过程中使用到的服务对象均来源于DI容器。该DI容器不仅为ASP.NET Core框架提供必要的服务,同时作为了应用的服务提供者,依赖注入已经成为了ASP.NET Core应用基本的编程模式。在前面一系列的文章中,我们主要从理论层面讲述了依赖注入这种设计模式,补充必要的理论基础是为了能够理解与ASP.NET Core框架无缝集成的依赖注入框架的设计原理。我们总是采用“先简单体验,后者深入剖析”来讲述每一个知识点,所以我们利用一些简单的实例从编程层面来体验一下服务注册的添加和服务实例的提取。
在《通过自定义配置实现插件式设计》中,通过在运行时对配置的动态解析实现了真正的“插件式”设计,其本质就是让配置自行提供对配置类型实例的创建。在这篇文章中,我们将更进一步,让自定义配置和IoC集成起来。IoC的目的就是通过解析注册的依赖注入信息,最终创建出我们希望的某个对象。而只有通过配置的方式来定义IoC容器需要的注入信息,才能实现灵活的设计。所以,如果将两者集成起来,让IoC容器能够解析通过配置定义的“依赖注入”信息,具有很大的现实意义。接下来,我们将通过Unity为例,介绍IoC和自定义进行无缝集成的实
在EnteLib中,PIAB(Policy Injection Application Block)和Unity的定位是轻量级的AOP框架和IoC容器(Container)。通过PIAB,我们可以将一些业务无关的crosscutting concern定义于相应的CallHandler中,通过Attribute声明或者配置应用到承载业务逻辑的目标方法上。而通过Unity提供的IoC容器(或者DI容器),即UnityContainer,很好地实现了依赖的动态注入,从而实现了组件之间、模块之间或者服务之间的松耦
所谓控制反转(IoC: Inversion Of Control)简单地说就是应用本身不负责依赖对象的创建和维护,而交给一个外部容器来负责。这样控制权就由应用转移到了外部IoC容器,控制权就实现了所谓的反转。比如在类型A中需要使用类型B的实例,而B实例的创建并不由A来负责,而是通过外部容器来创建。通过IoC的方式是实现针对目标Controller的激活具有重要的意义。 目录 一、从Unity来认识IoC 二、Controller与Model的分离 三、 创建基于Io
测试驱动 ASP.NET MVC Keith Burnell 下载代码示例 模型-视图-控制器 (MVC) 模式的核心是将 UI 功能划分成三个组成部分。模型表示您的领域的数据和行为。视图管理模型的显示并且处理与用户的交互。控制器协调视图和模型之间的交互。通过这样将本质上就难于测试的 UI 逻辑与业务逻辑分离开来,使得使用 MVC 模式实现的应用程序非常易于测试。在本文中,我将论述用于增强您的 ASP.NET MVC 应用程序的可测试性的最佳做法和技术,包括如何建立您的解决方案的结构、设计代码架构以便处理依
在ASP.NET MVC4中,为了在解开Controller和Model的耦合,我们通常需要在Controller激活系统中引入IoC,用于处理用户请求的Controller,让Controller依赖于ModelRepository的抽象而不是它的实现。 我们可以在三个阶段使用IoC实现上面所说的解耦操作,首先需要简单介绍一下默认情况下Controller的激活过程: 用户发送请求黑ASP.NET,路由系统对请求进行解析,根据注册的路由规则对请求进行匹配,解析出Controller和A
2. 开放/封闭原则: 添加任何新行为,应该是扩展到新类中,而不应该直接修改原来运行良好的代码。
IoC主要体现了这样一种设计思想:通过将一组通用流程的控制从应用转移到框架之中以实现对流程的复用,同时采用“好莱坞原则”是应用程序以被动的方式实现对流程的定制。我们可以采用若干设计模式以不同的方式实现IoC,比如我们在上面介绍的模板方法、工厂方法和抽象工厂,接下来我们介绍一种更为有价值的IoC模式,即依赖注入(DI:Dependency Injection,以下简称DI)。 目录 一、由外部容器提供服务对象 二、三种依赖注入方式 构造器注入 属性注入 方法注入 三、实例演示:创建
1.实例注册 最简单的注册方式就是实例注册,Unity 容器负责维护对一个类型的单例引用,比如: 有如下的实际类型: namespace ConsoleSample { public class SampleClass { public int ReferenceCount { get; set; } public void Increase() { this.ReferenceCount++; }
在采用了依赖注入的应用中,我们总是直接利用DI容器直接获取所需的服务实例,换句话说,DI容器起到了一个服务提供者的角色,它能够根据我们提供的服务描述信息提供一个可用的服务对象。ASP.NET Core中的DI容器体现为一个实现了IServiceProvider接口的对象。 ServiceProvider与ServiceDescriptor 服务的注册与提供 利用ServiceProvider来提供服务 提供一个服务实例的集合 获取ServiceProvider自身对象 对
在《原理篇》中我们谈到了通过自定义ServiceHost对WCF进行扩展的本质,以及在IIS/WAS寄宿情况下ServiceHostFactory的作用。接下来通过一个具体的例子来演示如何通过WCF扩展实现以Unity为代表的IoC框架的集成,以及应用该扩展的ServiceHost和ServiceHostFactory如何定义。[源代码从这里下载] 目录 一、IoC/DI简介 步骤一、自定义InstanceProvider:UnityInstanceProvider
该文介绍了如何在WindowsPhone和Android平台上使用SQLite数据库存储数据,并提供了具体的代码示例。
Unity是微软在CodePlex上的一个开源项目,可用于依赖注入、控制反转,类似Spring,下面是使用示例: 1.先来定义几个接口、类 1 namespace UnityTest 2 { 3
祝大家圣诞节快乐!有事没事别出门,外面太!挤!了! 此文是《.NET:框架设计原则、规范》的读书笔记,本文内容较多,共分九章,今天推送最后一章。 1. 什么是好的框架 2. 框架设计原则 3. 命名规范 4. 类型设计规范 5. 成员设计规范 6. 扩展性设计 7. 异常 8. 使用规范 9. 设计模式 一、设计模式 1. 聚合组件 Aggregate Component: 把多个底层类型集中到一个高层类型中,以此来支持常用场景。例如E-mail组件、System.Net.WebClient、System.
本系列文章旨在剖析.NET Core的依赖注入框架的实现原理,到目前为止我们通过三篇文章(《控制反转》、《基于IoC的设计模式》和《 依赖注入模式》)从纯理论的角度对依赖注入进行了深入论述,为了让读者朋友能够更好地理解.NET Core的依赖注入框架的设计思想和实现原理,我们创建了一个简易版本的DI框架,也就是我们在前面文章中多次提及的Cat。我们会上下两篇来介绍这个被称为为Cat的DI框架,上篇介绍编程模型,下篇关注设计实现。[源代码从这里下载]
领取专属 10元无门槛券
手把手带您无忧上云