依赖注入及AOP简述(十三)——AOP应用举例(完结) .

2.     AOP应用举例

在一般的应用程序开发中,有一些典型的AOP应用,使得开发者可以专注于业务逻辑本身,而不是与之完全无关的一些“方面”。

l        首先就是关于前面介绍过的日志输出类的功能,当然前面的例子非常简单,实际上要输出的日志信息中往往有很多的可变参数,这时就需要从被拦截对象的上下文中取出相应的信息进行行为的增强。

l        最常用的AOP应用就是关于DB事务的管理了。业务处理成功则向DB提交事务,反之则回滚事务——这是每一个开发者都会写过的代码。但是实际上这种事务的处理是完全独立的“方面”,不依赖于任何逻辑的实现,即任何有关DB的逻辑处理都是要提交或者回滚的,因此关于DB事务管理的功能往往由AOP框架去管理。Spring、Seam、Guice包括EJB应用中的容器管理事务的功能,实质上都是AOP的应用。

l        另外关于安全处理的功能,往往是和开发者所开发的逻辑无关的“方面”,因为所有需要判定当前的用户是否有权限执行某段逻辑这样的需求,一般都是同样的处理方式——用户有权限则继续处理,用户无权限则抛出异常。这种情况下为了避免开发者写出大量的if语句,用框架提供的AOP的方式去做安全的判定,应是最佳解决方案。

有关依赖注入设计模式的话题,其实是一个非常广泛的话题,不同的框架对其有着共同或不同的理念,所产生的最佳实践也有相似的一面和各不相同的一面,我们在这里由于篇幅有限,只能做以上的比较粗浅的介绍,大家如有兴趣可以继续通过互联网和各种书籍深入研究这种到目前为止非常成功的设计模式。

时间: 2024-10-11 11:26:49

依赖注入及AOP简述(十三)——AOP应用举例(完结) .的相关文章

[转]第二章 控制反转和依赖注入

Spring.Net 中提供了很多功能,比如依赖注入,面向切面编程(AOP),数据访问抽象以及ASP.Net扩展等等的功能.而其中最核心的功能就是依赖注入(Dependency Injection),而使用依赖注入带来的最大好处就是能够通过它降低应用程序中对象与对象之间的耦合. 控制反转(Inversion of Control)和 依赖注入(Dependency Injection),他们的英文缩写分别是IOC和DI,其实它们是同一个概念的不同角度的描述,由于控制反转概念比较模糊(可能只是理解

基于DDD的.NET开发框架 - ABP依赖注入

返回ABP系列 ABP是“ASP.NET Boilerplate Project (ASP.NET样板项目)”的简称. ASP.NET Boilerplate是一个用最佳实践和流行技术开发现代WEB应用程序的新起点,它旨在成为一个通用的WEB应用程序框架和项目模板. ABP的官方网站:http://www.aspnetboilerplate.com ABP官方文档:http://www.aspnetboilerplate.com/Pages/Documents Github上的开源项目:http

依赖注入及AOP简述(三)——依赖注入的原理

3.     “依赖注入”登场 于是诸多优秀的IT工程师开始想出了更加轻量便利.更加具有可测试性和可维护性的设计模式——IoC模式.IoC,即Inversion of Control的缩写,中文里被称作“控制反转”.至于为什么会有这么一个看似古怪的名字,我们稍后会做解释.2004年著名软件工程学者和工程师Martin Fowler在其论文<Inversion ofControl Containers and the Dependency Injection pattern>中将IoC更名为De

依赖注入及AOP简述(十二)——依赖注入对象的行为增强(AOP) .

四.依赖注入对象的行为增强(AOP) 前面讲到,依赖注入框架的最鲜明的特点就是能够提供受容器管理的依赖对象,并且可以对对象提供行为增强(AOP)功能,所以这一章我们来讨论有关AOP的话题. 1.     对依赖对象进行行为增强 所谓AOP,就是Aspect Oriented Programming(面向方面的编程),核心思想是把一个“方面”独立出来,从而实现组件间的松耦合.也许有些晦涩难懂,所以我们还是看个简单的例子. 在我们的银行依赖中,假设有个需求,即在每一笔取款业务的前后都要输出日志信息.

依赖注入及AOP简述(九)——单例和无状态Scope .

三.依赖注入对象的Scope及其生命周期 在前面的章节我们讲到,依赖注入容器之所以能够区别于以往的ServiceLocator等容器,是在于其不但能够自动构建多层次的.完整的依赖关系图,并且可以管理依赖对象的Scope和对其进行行为增强.有关行为增强的话题我们会在下一章介绍,这里我们先来看看有关依赖对象的Scope及其生命周期管理的话题. 1.     依赖注入对象的Scope Scope,即作用域,是指面向对象开发中所设计的某一类对象的生存期间.我们先从普通Java程序开发中最常用的单例和无状

依赖注入及AOP简述(四)——“好莱坞原则”和依赖注入框架简介 .

3.2.    “好莱坞原则” 看了前面关于依赖注入概念的描述,我们来提炼出依赖注入的核心思想.如果说传统的组件间耦合方式,例如new.工厂模式等,是一种由开发者主动去构建依赖对象的话,那么依赖注入模式则是其反向的,即被动地等待别人做好一个依赖对象提供给我. 在美国好莱坞众多电影工厂在寻找演员的时候通常奉行着这么一个原则:不要找我,需要的时候我去找你(“Don’tcall us; we’ll call you!”),把相同的思路运用到我们的软件工程里通常也被称作“好莱坞原则”(Hollywood

依赖注入及AOP简述(五)——依赖注入的方式 .

二.依赖注入的应用模式 前面我们了解了依赖注入的基本概念,也对一些依赖注入框架进行了简单的介绍,这一章我们主要来讨论作为开发者如何利用依赖注入框架来实现依赖注入的设计思想. 1.     依赖注入的方式 前面我们提到,所谓“依赖”,最简单地去解释就是一个Java类里的成员变量.我们都知道,给一个类中的私有成员变量赋值的方法通常有:通过Constructor构造方法.通过Setter方法.通过反射机制将私有变量的可见性设为true这三种方法.同样道理,依赖注入框架也是利用这三种方式来完成依赖对象的

依赖注入及AOP简述(七)——FQCN请求模式

2.2.    FQCN请求模式 为了弥补纯字符串请求模式中的类型安全问题,全类名(FQCN)请求模式就应运而生了.其思想便是,在向容器请求依赖对象的时候,不是通过字符串的标识符.而是通过被请求的依赖的全类名来定位依赖.这样如果开发者误将全类名标识符写错的话,在编译时立即会提醒“类不存在”.并且,如果使用Eclipse等IDE开发工具的话,用其提供的自动完整代码的功能就会轻松地将依赖的全类名标识符定义到代码中. 在第一章的“3.3 依赖注入框架简介”一节中我们提到了Google Guice框架是

依赖注入及AOP简述(十一)——生命周期管理 .

2.     生命周期管理 各种依赖注入框架提供了替开发者管理各种Scope的便利功能,随之而来的就必然是被管理的依赖对象的生命周期管理的问题.所谓生命周期管理,就是一个对象在它所属的Scope中从被容器创建开始.到被提供给依赖者.再到最后的消亡这一整个过程中,依赖注入框架提供了一系列的回调方法的接口,使框架自身以及开发者都可以利用这些接口对各个生存时点的依赖对象做一些操作和管理等. 例如依赖注入容器在创建一个依赖对象的时候,远不是new一个对象那么简单,而是一个极其复杂地Wrap这个对象的过程