随笔分类 - [05] 开源框架
摘要：
相较于社区其他主流的AOP框架，Dora.Interception在Interceptor提供了完全不同的编程方式。我们并没有为Interceptor定义一个接口，正是因为不需要实现一个预定义的接口，Dora.Interception下的Interceptor定义变得更加自由。除此之外，Interceptor的异步执行是我在设计Dora.Interception之初最为关心的问题，也就是说如果Interceptor应用的目标方法是异步的，Interceptor自身也应该被赋予异步执行的能力。接下来我们就来聊聊如果你使用了Dora.Interception，如何定义你的InterceptorDora.Interception之初最为关心的问题，也就是说如果Interceptor应用的目标方法是异步的，Interceptor自身也应该被赋予异步执行的能力。接下来我们就来聊聊如果你使用了Dora.Intercep
阅读全文
相较于社区其他主流的AOP框架，Dora.Interception在Interceptor提供了完全不同的编程方式。我们并没有为Interceptor定义一个接口，正是因为不需要实现一个预定义的接口，Dora.Interception下的Interceptor定义变得更加自由。除此之外，Interceptor的异步执行是我在设计Dora.Interception之初最为关心的问题，也就是说如果Interceptor应用的目标方法是异步的，Interceptor自身也应该被赋予异步执行的能力。接下来我们就来聊聊如果你使用了Dora.Interception，如何定义你的InterceptorDora.Interception之初最为关心的问题，也就是说如果Interceptor应用的目标方法是异步的，Interceptor自身也应该被赋予异步执行的能力。接下来我们就来聊聊如果你使用了Dora.Intercep
阅读全文
摘要：Dora.Interception 1.0（Github地址：可以访问GitHub地址：https://github.com/jiangjinnan/Dora）推出有一段时间了，最近花了点时间将它升级到2.0。
阅读全文
Dora.Interception 1.0（Github地址：可以访问GitHub地址：https://github.com/jiangjinnan/Dora）推出有一段时间了，最近花了点时间将它升级到2.0。
阅读全文
摘要：
多年从事框架设计开发使我有了一种强迫症，那就是见不得一个应用里频繁地出现重复的代码。之前经常Review别人的代码，一看到这样的程序，我就会想如何将这些重复的代码写在一个地方，然后采用“注入”的方式将它们放到需要的程序中。我们知道AOP是解决这类问题最理想的方案。为此，我自己写了一个AOP框架，该框架被命名为Dora.Interception。Dora.Interception已经在GitHub上开源，如果有兴趣的朋友想下载源代码或者阅读相关文档，可以访问GitHub地址：
阅读全文
多年从事框架设计开发使我有了一种强迫症，那就是见不得一个应用里频繁地出现重复的代码。之前经常Review别人的代码，一看到这样的程序，我就会想如何将这些重复的代码写在一个地方，然后采用“注入”的方式将它们放到需要的程序中。我们知道AOP是解决这类问题最理想的方案。为此，我自己写了一个AOP框架，该框架被命名为Dora.Interception。Dora.Interception已经在GitHub上开源，如果有兴趣的朋友想下载源代码或者阅读相关文档，可以访问GitHub地址：
阅读全文
摘要：ASP.NET Core具有一个以ServiceCollection和ServiceProvider为核心的依赖注入框架，虽然这只是一个很轻量级的框架，但是在大部分情况下能够满足我们的需要。不过我觉得它最缺乏的是针对AOP的支持，虽然这个依赖注入框架提供了扩展点使我们可以很容易地实现与第三方框架的集成，但是我又不想“节外生枝”，为此我们趁这个周末写了一个简单的Interception框架来解决这个问题。通过这个命名为Dora.Interception的框架，我们可以采用一种非常简单、直接而优雅地（呵呵）在这个原生的DI框架上实现针对AOP的编程。
阅读全文
ASP.NET Core具有一个以ServiceCollection和ServiceProvider为核心的依赖注入框架，虽然这只是一个很轻量级的框架，但是在大部分情况下能够满足我们的需要。不过我觉得它最缺乏的是针对AOP的支持，虽然这个依赖注入框架提供了扩展点使我们可以很容易地实现与第三方框架的集成，但是我又不想“节外生枝”，为此我们趁这个周末写了一个简单的Interception框架来解决这个问题。通过这个命名为Dora.Interception的框架，我们可以采用一种非常简单、直接而优雅地（呵呵）在这个原生的DI框架上实现针对AOP的编程。
阅读全文
摘要：
Unity是微软P&P部门开发的一个轻量级IoC框架，通过Interception机制可以实现基于三种拦截机制的AOP。不过Unity仅仅提供“显式”拦截机制，以致我们为了注册可被拦截的类型会多写很多代码和配置。本篇文章通过UnityContainer的扩展提供了一种“自动”拦截机制。
阅读全文
Unity是微软P&P部门开发的一个轻量级IoC框架，通过Interception机制可以实现基于三种拦截机制的AOP。不过Unity仅仅提供“显式”拦截机制，以致我们为了注册可被拦截的类型会多写很多代码和配置。本篇文章通过UnityContainer的扩展提供了一种“自动”拦截机制。
阅读全文
摘要：个人觉得EnterLib的EHAB是一个不错的异常处理框架，借助于EHAB，我们可以配置的方式来自定义异常处理策略，从而带来最大的灵活性和可维护性。但是，在我看来，EHAB有一个最大的局限，就是异常处理策略的粒度过大——只能提供基于异常类型级别。本篇文章通过一个自定义异常处理器很好地解决了这个问题。
阅读全文
个人觉得EnterLib的EHAB是一个不错的异常处理框架，借助于EHAB，我们可以配置的方式来自定义异常处理策略，从而带来最大的灵活性和可维护性。但是，在我看来，EHAB有一个最大的局限，就是异常处理策略的粒度过大——只能提供基于异常类型级别。本篇文章通过一个自定义异常处理器很好地解决了这个问题。
阅读全文
摘要：在上篇文章中我们谈到：当我们通过应用DependencyAttribute特性定义需要自动注入的属性的时候，当这个属性为接口、抽象类或者没有定义无参的构造函数，无论我们调用PIAB的Create方法去创建一个新的对象，还是调用Wrap方法对现有对象进行封装，都会抛出异常。如果说在前文中，我们还对这是否是个BUG抱着“谨慎”的态度，那么在这篇文章中，可以肯定地告诉你：这是一个BUG，而且是一个“致命”的BUG。
阅读全文
在上篇文章中我们谈到：当我们通过应用DependencyAttribute特性定义需要自动注入的属性的时候，当这个属性为接口、抽象类或者没有定义无参的构造函数，无论我们调用PIAB的Create方法去创建一个新的对象，还是调用Wrap方法对现有对象进行封装，都会抛出异常。如果说在前文中，我们还对这是否是个BUG抱着“谨慎”的态度，那么在这篇文章中，可以肯定地告诉你：这是一个BUG，而且是一个“致命”的BUG。
阅读全文
摘要：之前园子里也有一些介绍企业库的文章，其中也不乏对Unity的介绍。虽然微软官方声称其为轻量级的IoC框架，但是并不意味着Unity会很简单。相反，也正是因为复杂性，很多人撰文介绍Unity的时候，往往为了面面俱到，导致很多读者不知所云。最终的结果是，了解Unity的读者能够看懂，不懂的人读了还是不懂。在本篇文章中，我试着换一种介绍方式：抓住Unity最本质的东西，剔除一些细枝末节，希望以一种全新的视角让读者了解Unity的本质。
阅读全文
之前园子里也有一些介绍企业库的文章，其中也不乏对Unity的介绍。虽然微软官方声称其为轻量级的IoC框架，但是并不意味着Unity会很简单。相反，也正是因为复杂性，很多人撰文介绍Unity的时候，往往为了面面俱到，导致很多读者不知所云。最终的结果是，了解Unity的读者能够看懂，不懂的人读了还是不懂。在本篇文章中，我试着换一种介绍方式：抓住Unity最本质的东西，剔除一些细枝末节，希望以一种全新的视角让读者了解Unity的本质。
阅读全文
摘要：微软EnterLib的PIAB是一个比较好用的轻量级的AOP框架，自身也提供了一系列的CallHandler，其中CachingCallHandler直接利用HttpRuntime的Cache实现了基于方法级别的缓存。但是，PIAB发布到现在，CachingCallHandler就一直存着一个问题：如果目标方法具有Out参数并且返回类型不是void，会抛出IndexOutOfRangeException，如果返回类型为void，out参数也不会被缓存。不知道微软对此作何考虑，反正我觉得这是一个不可原谅的Bug。
阅读全文
微软EnterLib的PIAB是一个比较好用的轻量级的AOP框架，自身也提供了一系列的CallHandler，其中CachingCallHandler直接利用HttpRuntime的Cache实现了基于方法级别的缓存。但是，PIAB发布到现在，CachingCallHandler就一直存着一个问题：如果目标方法具有Out参数并且返回类型不是void，会抛出IndexOutOfRangeException，如果返回类型为void，out参数也不会被缓存。不知道微软对此作何考虑，反正我觉得这是一个不可原谅的Bug。
阅读全文
摘要：
Enterprise Library是微软P&P部门开发的众多Open source框架中的一个，最新的版本已经出到了4.1。由于接触Enterprise Library已经有很长的一段时间，在实际的项目中使用的频率也很高。对此有了一些积累，希望通过这个新的系列和广大网友一起分享和交流。本系列假设读者已经对Enterprise Library有一定的了解，故而不会对各个Application Block的基本原理和编程模型进行介绍，而把侧重点放在Enterprise Library深层次的实现原理、设计模式的应用、有效扩展和最佳实践上
阅读全文
Enterprise Library是微软P&P部门开发的众多Open source框架中的一个，最新的版本已经出到了4.1。由于接触Enterprise Library已经有很长的一段时间，在实际的项目中使用的频率也很高。对此有了一些积累，希望通过这个新的系列和广大网友一起分享和交流。本系列假设读者已经对Enterprise Library有一定的了解，故而不会对各个Application Block的基本原理和编程模型进行介绍，而把侧重点放在Enterprise Library深层次的实现原理、设计模式的应用、有效扩展和最佳实践上
阅读全文
摘要：在上篇中，我详细介绍了如何通过自定义ClientMessageInspector和ErrorHandler，实现WCF与微软企业库中的Exception Handling Application Block（EHAB）之间的集成。本篇中，我们对其加以改进，使你不需要再为每个操作应用相同的FaultContractAttribute。
阅读全文
在上篇中，我详细介绍了如何通过自定义ClientMessageInspector和ErrorHandler，实现WCF与微软企业库中的Exception Handling Application Block（EHAB）之间的集成。本篇中，我们对其加以改进，使你不需要再为每个操作应用相同的FaultContractAttribute。
阅读全文
摘要：在《WCF技术剖析（卷1）》的最后一章，我给出了一个具体的应用WCF的分布式应用实例，我把这个实例命名为PetShop。看过本书的读者，一定还记得我还通过WCF扩展实现了于微软企业库（Enterprise Library）异常处理应用块（Exception Handling Application Block：EHAB）的集成,现在我们可以详细来讲述这是如何实现的。
阅读全文
在《WCF技术剖析（卷1）》的最后一章，我给出了一个具体的应用WCF的分布式应用实例，我把这个实例命名为PetShop。看过本书的读者，一定还记得我还通过WCF扩展实现了于微软企业库（Enterprise Library）异常处理应用块（Exception Handling Application Block：EHAB）的集成,现在我们可以详细来讲述这是如何实现的。
阅读全文
摘要：
在这之前，我写过深入介绍MS EnterLib PIAB的文章（参阅《MS Enterprise Library Policy Injection Application Block 深入解析[总结篇]》），也写过WCF与PIAB的集成（参阅：《WCF后续之旅（8）：通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成》）、WCF与Unity的集成（参阅《WCF后续之旅（7）：通过WCF Extension实现和Enterprise Library Unity Container的集成》）以及Unity与PIAB的集成（参阅《Enterprise Library深入解析与灵活应用（1）：通过Unity Extension实现和Policy Injection Application Block的集成》、
阅读全文
在这之前，我写过深入介绍MS EnterLib PIAB的文章（参阅《MS Enterprise Library Policy Injection Application Block 深入解析[总结篇]》），也写过WCF与PIAB的集成（参阅：《WCF后续之旅（8）：通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成》）、WCF与Unity的集成（参阅《WCF后续之旅（7）：通过WCF Extension实现和Enterprise Library Unity Container的集成》）以及Unity与PIAB的集成（参阅《Enterprise Library深入解析与灵活应用（1）：通过Unity Extension实现和Policy Injection Application Block的集成》、
阅读全文
摘要：在EnteLib中，PIAB（Policy Injection Application Block）和Unity的定位是轻量级的AOP框架和IoC容器（Container）。通过PIAB，我们可以将一些业务无关的crosscutting concern定义于相应的CallHandler中，通过Attribute声明或者配置应用到承载业务逻辑的目标方法上。而通过Unity提供的IoC容器（或者DI容器），即UnityContainer，很好地实现了依赖的动态注入，从而实现了组件之间、模块之间或者服务之间的松耦合。在本篇文章中,我们将关注如何将两者有机地关联起来。
阅读全文
在EnteLib中，PIAB（Policy Injection Application Block）和Unity的定位是轻量级的AOP框架和IoC容器（Container）。通过PIAB，我们可以将一些业务无关的crosscutting concern定义于相应的CallHandler中，通过Attribute声明或者配置应用到承载业务逻辑的目标方法上。而通过Unity提供的IoC容器（或者DI容器），即UnityContainer，很好地实现了依赖的动态注入，从而实现了组件之间、模块之间或者服务之间的松耦合。在本篇文章中,我们将关注如何将两者有机地关联起来。
阅读全文
摘要：开门见山，使用MS Enterprise Library的DAAB（Data Access Application Block）获取数据时抛出异常。具体场景如下，通过Database对象的ExecuteReader执行两段Select语句，前一句是不合法的，后一句是正确的。为了避免第一次执行出错导致程序的终止，特意将其放到Try/Catch酷快中。两次数据库操作通过TrsanctionScope的形式纳入同一个Transaction中，具体的代码如下所示。
阅读全文
开门见山，使用MS Enterprise Library的DAAB（Data Access Application Block）获取数据时抛出异常。具体场景如下，通过Database对象的ExecuteReader执行两段Select语句，前一句是不合法的，后一句是正确的。为了避免第一次执行出错导致程序的终止，特意将其放到Try/Catch酷快中。两次数据库操作通过TrsanctionScope的形式纳入同一个Transaction中，具体的代码如下所示。
阅读全文
摘要：基于Enterprise Library PIAB的AOP框架已经在公司项目开发中得到广泛的使用，但是最近同事维护一个老的项目，使用到了Enterprise Library 2，所以PIAB是在Enterprise Library 3.0中推出的，所以不同直接使用。为了解决这个问题，我写了一个通过方法劫持（Method Interception）的原理，写了一个简易版的AOP框架。
阅读全文
基于Enterprise Library PIAB的AOP框架已经在公司项目开发中得到广泛的使用，但是最近同事维护一个老的项目，使用到了Enterprise Library 2，所以PIAB是在Enterprise Library 3.0中推出的，所以不同直接使用。为了解决这个问题，我写了一个通过方法劫持（Method Interception）的原理，写了一个简易版的AOP框架。
阅读全文
摘要：这个工具执行一组批处理，也可以看成是一个Sequential Workflow的执行器，我把它成为Batch Job Executor。在使用Batch Job Executor过程中，通过配置可以对批处理的每个步骤、或者是Workflow的每个Activity进行自由地定义。从功能上将，这个小工具仅仅是个小玩意儿，不登大雅之堂。 不过考虑到Batch Job Executor的涉及和实现是基于Enterprise Library典型的实现方式，比如基于EL的配置和对象创建方式，对于那些希望进一步了解EL的读者，或许可以通过这个小小的例子一窥EL的设计原理。对于那些EL的设计不时很了解的读者，对于以下的内容，可能在理解上可能比较困难。最好是下载源代码，结合下面的介绍，希望会帮助了更好的理解EL。
阅读全文
这个工具执行一组批处理，也可以看成是一个Sequential Workflow的执行器，我把它成为Batch Job Executor。在使用Batch Job Executor过程中，通过配置可以对批处理的每个步骤、或者是Workflow的每个Activity进行自由地定义。从功能上将，这个小工具仅仅是个小玩意儿，不登大雅之堂。 不过考虑到Batch Job Executor的涉及和实现是基于Enterprise Library典型的实现方式，比如基于EL的配置和对象创建方式，对于那些希望进一步了解EL的读者，或许可以通过这个小小的例子一窥EL的设计原理。对于那些EL的设计不时很了解的读者，对于以下的内容，可能在理解上可能比较困难。最好是下载源代码，结合下面的介绍，希望会帮助了更好的理解EL。
阅读全文
摘要：[From J.D Meier’s Blog:http://blogs.msdn.com/jmeier/default.aspx]
Today we released our patterns & practices App Arch Guide 2.0 Beta 1. This is our guide to help solution architects and developers make the most of the Microsoft platform. It's a distillation of many lessons learned. It’s principle-based and pattern-oriented to provide
阅读全文
[From J.D Meier’s Blog:http://blogs.msdn.com/jmeier/default.aspx]
Today we released our patterns & practices App Arch Guide 2.0 Beta 1. This is our guide to help solution architects and developers make the most of the Microsoft platform. It's a distillation of many lessons learned. It’s principle-based and pattern-oriented to provide
阅读全文
摘要：微软Enterprise Library ELAB（Exception Handling Application Block）提供了一种基于策略（Policy）的异常处理方式，在不同的环境中，比如多层架构中不同的层次中，我们可以定义不同的异常处理策略。对于ELAB来说，Exception Handling Policy = Exception Type + Exception Handler(s) ，也就是说异常处理策略规定了对于某种类型的类型需要通过那些Exception Handler去处理。从这种意义上讲，ELAB的异常处理机制是基于Exception Type的，异常的类型是我们处理异常的最小粒度。对于一个确定的异常处理策略，在不同场合抛出的同种类型的异常，都会使用相同的Exception Handler去处理。在很多情况下，这种基于异常类型级别的异常处理并不能解决我们实际异常处理的问题。
阅读全文
微软Enterprise Library ELAB（Exception Handling Application Block）提供了一种基于策略（Policy）的异常处理方式，在不同的环境中，比如多层架构中不同的层次中，我们可以定义不同的异常处理策略。对于ELAB来说，Exception Handling Policy = Exception Type + Exception Handler(s) ，也就是说异常处理策略规定了对于某种类型的类型需要通过那些Exception Handler去处理。从这种意义上讲，ELAB的异常处理机制是基于Exception Type的，异常的类型是我们处理异常的最小粒度。对于一个确定的异常处理策略，在不同场合抛出的同种类型的异常，都会使用相同的Exception Handler去处理。在很多情况下，这种基于异常类型级别的异常处理并不能解决我们实际异常处理的问题。
阅读全文
摘要：最近在做一个Smart Client Software Factory的项目。熟悉SCSF或者CAB的都应该很清楚MVP这种设计模式。MVP是MVC的一种变体，View和Mode分别关注于UI的呈现和业务模型，View和Mode完全分离，View通过Presenter实现对业务模型的访问，Presenter“间接”地调用View实现对UI的操作。对于MVP中的异常处理，我们是直接通过Enterprise Library的Exception Handling Application Block来实现的。具体的做法是：在View中的每个控件的事件中添加try/catch block， 并在catch中通过ExceptionPolicy实现对异常的处理。这样导致的问题是，相同的代码重复散
阅读全文
最近在做一个Smart Client Software Factory的项目。熟悉SCSF或者CAB的都应该很清楚MVP这种设计模式。MVP是MVC的一种变体，View和Mode分别关注于UI的呈现和业务模型，View和Mode完全分离，View通过Presenter实现对业务模型的访问，Presenter“间接”地调用View实现对UI的操作。对于MVP中的异常处理，我们是直接通过Enterprise Library的Exception Handling Application Block来实现的。具体的做法是：在View中的每个控件的事件中添加try/catch block， 并在catch中通过ExceptionPolicy实现对异常的处理。这样导致的问题是，相同的代码重复散
阅读全文