<br />在《这是EnterLib PIAB的BUG吗？》一文中我们讨论了PIAB关于抽象基类的BUG，今天又发现了一个新的问题。问题的起因源于《IoC+AOP的简单实现》这篇文章，因为文中给出的解决方案仅仅支持构造器注入（Constructor Injection），而不能支持属性注入（Property Injection）和方法注入（Method Injection）。这是由于EnterLib的PIAB设计本身就存在缺陷。<br />对EnterLib 5.0有一定了解的人都应该知道，在新版本的Ent

<br />在《这是EnterLib PIAB的BUG吗？》一文中我们讨论了PIAB关于抽象基类的BUG，今天又发现了一个新的问题。问题的起因源于《IoC+AOP的简单实现》这篇文章，因为文中给出的解决方案仅仅支持构造器注入（Constructor Injection），而不能支持属性注入（Property Injection）和方法注入（Method Injection）。这是由于EnterLib的PIAB设计本身就存在缺陷。<br />对EnterLib 5.0有一定了解的人都应该知道，在新版本的Ent

<br />关于“验证框架”，先后推出了《编程篇》、《设计篇》和《改进篇》，本不打算再写《XXX篇》的。但是今天收到两个园友的短消息，想了解一下如何定义自己的验证规则。这实际上涉及到对该“验证框架”的扩展，即如何自定义Validator和对应的ValidatorAttribute与ValidatorElementAttribute。为了让本系列看起来完整，通过《扩展篇》进行收尾。本篇我们写一个简单的Validator，用于验证字符串类型属性成员的长度是否符合要求（实际上我是直接借鉴了EnterLib中VAB