摘要：我们都知道Asp.Net2.0中aspx文件结构相比以前有了很大的改变。当然，其中大多数是改善，比如，在page的source code界面的内嵌代码支持智能提示了，不过这个智能提示也有小小小的不爽，就是除非是System.Web等几个默认的命名空间中的类，访问其他命名空间的类如果不添加Namespace引用的话就必须用完全路径访问（我的类前面的命名空间前缀会很长啊，很难看的）；有一些改善也带来一些限制，比如，除非在页面/用户控件中显式import其他页面/用户控件，否则是不能访问到外部类型的，感觉就好像这个页面/控件自己一个人带一个程序集。为了合理避免一些限制造成的语法的不爽和合理利用新的智能功能，Teddy在本文中向您展示一组MasterPage/Page/UserControl通用基类封装，他们将为您提供许多非常方便的功能和语法体验。当然，唯一的代价是，你的Page/MasterPage/UserControl必须从我的基类继承，当然，从我的基类继承的对象和从默认系统基类继承的对象是可以自由混合使用的，付出这一点点代价，您在下文中将会看到，绝对是值得的。 br 阅读全文

摘要：本文介绍本人的一个简单Object Pool实现。什么是Object Pool呢？大家可能都知道什么是数据库连接池，他能极大避免不需要的对象销毁和初始化开销。本文实现的对象池是一个通用的可用于任何有实例化接口的对象的池。默认的对象的实例化接口是new，文中也演示了如果您的对象需要从一个Factory构造，或当你的对象是用Emit生成时，如何简单继承ObjectPool类，实现特殊的对象的池化操作。 阅读全文

摘要：在上一篇《来一点反射，再来一点Emit —— 极度简化Entity！》中，Teddy运用反射和Emit极度简化了Entity的定义方式。本文将在上文的基础上，用自定义KeyValueCollection类代替原来的Dictionary类承载Entity的数据，从而改善Entity的读写性能，并保持Dictionary的方便的使用接口。 阅读全文

摘要：在前一篇文章《没有ORM或代码生成数据就不能持久化了？ - 用范型技术代替代码生成！》中，Teddy尝试运用泛型极大简化了一个轻量级持久化框架对代码生成的依赖，并且为了保证性能，整个持久化组件没有使用反射。在本文中，Teddy将在保证性能的基础上，加一点反射和加一点Emit，从而进一步简化Entity的定义和使用，当然也就进一步降低了组件对传统代码生成的依赖。读者可以对比前文阅读本文，看看改进的效果。内容绝对精彩，不容错过哟！ 阅读全文

摘要：在本文中，Teddy将在对C#2.0中的范型编程的理解的基础上，列举一个应用范型技术以改善以前一些通常只能通过代码生成方式实现的软件构架的实践。文中，Teddy将给出利用范型技术重写一个自己原来基于代码生成思想所写的持久化层方案。新的范型方案既不依赖ORM，也不依赖代码生成，只需定义需要的数据库结构和实体类的基本结构（当然，如果还想偷懒，也完全可以写个简单程序生成实体类）就能够获得非常方便的持久化支持。为了改善程序的执行效率，程序中甚至完全避免了使用可能会影响执行效率的反射，并且充分在可能的地方充分运用了Cache模式以避免不必要的性能损失。 阅读全文

摘要： 在本人之前的《Component/Service Oriented Software System Development Thinking 》一文中，我将包括BinaryLevel和Source Code Level的软件模块统称为Component。这种分类方式，和传统的对Component的一般定义应该说并不是十分一致。本文就是要对我为什么要这样分类作一些补充解释。 阅读全文

摘要： 本文是Teddy关于基于组件及服务为中心的软件系统开发的进一步思考的系列文章的第一篇，探讨Teddy对当前的基于组件及服务的软件系统开发现状及基本思想的理解。本系列文章一共三篇，在之后两篇中Teddy将站在“组件”这样一个点上分别Looking into组件和Looking outside“组件”这个点，从而分别思考对第一篇中描述的软件开发模型的改进的可能方案。Teddy并非软件开发方面的资深专家，而只是一位喜欢思考的普通程序员，对软件开发这样一门科学的认识难免是具有非常的局限性的，因此，本文的观点仅代表Teddy的个人见解，如果您认为文中的观点过于奇特或幼稚，或者有失偏颇的，欢迎给与批评指教。 阅读全文

摘要： 前面谈到SOA，思维可能确实有点发散，但是，我还是坚持这样一种更高抽象层次的Service Oriented设计思想绝对是有益的。当然这个有待实践检验。另一方面，本人正在规划中的一个SOAHelper开源框架将会为基于通用的SOA思想的开发提供一些便利，当然，这里提到的SOA都不是业界对SOA严格的标准定义。而是更高层次的抽象，不过，对于严格的SOA，同样是有益的，不，应该是主要的服务对象。这个就是后话了，这里随便提一下。回到正题，本文是重新诠释SOA & AOP的下篇，即重新诠释AOP。大家放心，本篇不会像SOA那样发散，以至于什么都是AOP，毕竟AOP还是以OO为基础的抽象思想的扩展，这里谈论的主题还是在于AOP的意义及怎样的AOP实现方式是AOP未来的发展趋势，尤其会阐述一种所谓容器式的二进制/IL级别基于AOP的拦截机制。 阅读全文

摘要： 虽然写了不少AOP的文章了，也没少关注SOA，不过最近才发现自己以前的认识多少有些狭隘，不，应该说非常狭隘才是。在这里，我要结合自己最近的感悟，重新诠释一下什么是SOA，什么是AOP。本文原出处为我的MSN SPACE，原文标题是重新阐述SOA和AOP，因为实在写得太长了点，这里分成两篇来写，这是第一篇：重新阐述SOA。之后还会有下一篇，重新阐述AOP，敬请期待！ 阅读全文