框架在开发完成之时,还并没有涉及到面向方面之类的一些东西,虽然框架能够满足
大部分的应用需要,但我们不得不在实际的开发过程中面临很尴尬的问题,在一些纯粹的
业务代码里面要加入很多不相关的代码,而这些代码本和业务逻辑和数据库操作没有任何关系
比如:最简单的就是日志,复杂一点的 事务处理 , 权限控制等等
这些讨厌的代码无孔不入的在你的任何的方法头或者尾上出现
public void Business_Flow()
{
Logging();
业务代码
logging();
}
上述的代码几乎每个项目中都会出现,开发人员能对Logging方法进行很好的封装,但依然不能避免
在业务逻辑代码中出现它们的身影。
而关注横切面思想编程模型,AOP即可以很好的解决这个问题
我没有写AOP的核心代码,我实际上是使用已经存在的AOP框架并自己加以改造后融入到自己的框架里面的。
我使用了 Castle组件中的AOP模型(关于这个模型的使用,这里就不在描述了,可一上其网站 http://www.castleproject.org/)
我直接引用了源代码,只是对AspectSharp项目进行增加,以符合自己框架的需求
目录ApectConfig是我自己添加的,主要是创建配置文件上的各个节点
类AspectSharpConfigurationHandler 主要是解析配置文件,并组装成Castle组件中的AOP模型识别的格式
<configSections>
<section name="AspectConfigSource"
type="AspectSharp.AspectConfig.AspectConfigSource, AspectSharp"/>
</configSections>
<!-- AspectSharp settings-->
<AspectConfigSource>
<ImportConfigCollection>
<addImportFullType="AOP.InterceptorApplication" Assembly="AOP.InterceptorApplication" />
<add ImportFullType="CoreLibray" Assembly="CoreLibray" />
<add ImportFullType="Business" Assembly="Business" />
</ImportConfigCollection>
<InterceptorConfigCollection>
<add InterceptorsAlias="Elogger"InterceptorsRealName="LoggerInterceptor"/>
<add InterceptorsAlias="ETransactionScope"InterceptorsRealName="TransactionScopeInterceptor"/>
<add InterceptorsAlias="ERequiredCOMPlus"InterceptorsRealName="RequiredCOMPlusTransactionInterceptor"/>
</InterceptorConfigCollection>
<AspectInterfaceConfigCollection>
<add Name="InterfaceLogger"AssignableFrom="IDataMapper"
PointcutMethod="method(* Delete(*))"Advice="Elogger"/>
<add Name="InterfaceTransactionScope"AssignableFrom="IDataMapper"
PointcutMethod="method(* Insert(*))"Advice="ERequiredCOMPlus"/>
</AspectInterfaceConfigCollection>
<AspectClassConfigCollection/>
</AspectConfigSource>
配置文件描述:
ImportConfigCollection 配置节 描述要引用的类库
InterceptorConfigCollection 配置节 描述注入的功能
AspectInterfaceConfigCollection 配置节 描述哪些接口方法被使用
这里可以看出 接口IDataMapper中的Delete()方法 要进行日志处理
接口IDataMapper中的Insert()方法要进行分布式事务处理
以下是代码了,可能有点长,但通过代码和上面额度配置文件可以了解如何使用
//我专门建立了一个类UsersBusinessOfAOP
public class UsersBusinessOfAOP
{
public Guid NewUser(Users user)
{
//使用AOP进行注册,表示将启用AOP技术
IDataMapper objUsersDataMapper =AOPDataMapperRegistry.GetDataMapper(typeof(Users).Name);
Guid key = objUsersDataMapper.Insert(user);
return key;
}
}
从以上配置文件看出,对IDataMapper接口的Insert方法进行横切控制,
在上面的这个业务逻辑代码中看不到有任何事务代码的例子,十分清爽
那么事务代码在哪里呢?
在这个另外建立的项目中,和上面的那个业务项目工程没有任何关系
namespace AOP.InterceptorApplication
{
public classRequiredCOMPlusTransactionInterceptor : IMethodInterceptor
{
#region IMethodInterceptor Members
public object Invoke(IMethodInvocation invocation)
{
RequiredCOMPlusTransaction COMPLusTS = newRequiredCOMPlusTransaction();
object result = null;
try
{
result = invocation.Proceed(); //这个就是刚才看见的那个Insert方法的执行点
COMPLusTS.Commit();
return result;
}
catch (Exception ex)
{
COMPLusTS.Abort();
return null;
}
}
#endregion
}
}
//如果配置文件是指向的TransactionScope的话,就是执行下面这个代码
public class TransactionScopeInterceptor : IMethodInterceptor
{
#region IMethodInterceptor Members
public object Invoke(IMethodInvocation invocation)
{
object result = null;
try
{
using (TransactionScope TS = new TransactionScope())
{
result = invocation.Proceed();
TS.Complete();
}
return result;
}
catch (Exception ex)
{
throw ex;
}
}
#endregion
}
从测试结果来看,事务顺利执行了,测试调试界面就不再这里帖出来了。
从以上可以看出,AOP的优越之处,完全不用在原来的项目中去做什么,只需要重新写个项目即可,当然罗
业务系统至少得启用配置文件,各个控制类和业务类应该都继承接口,这是最基本得条件,如果这些都不满足,AOP
得实现就很麻烦了
注意:这里建议用接口,不要使用类,因为直接的类有限制,要类的方法是virtual,因此在设计的时候尽量用接口编程
,这些就没什么问题了。
AOP面向方面的横切思想模型是对面向对象的有力补充,是一个值得深入研究的思想技术。
AOP的成功应用,给框架搭载上了一个飞翔的翅膀。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/gsnidi2002/archive/2008/09/04/2882167.aspx