Teddy's Knowledge Base

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

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

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

这几天整理自己的电脑，翻出以前载的一本电子书——RedSword软件工作室制作的《设计模式迷你手册》，忍不住拿来重读一遍，也检验一下自己目前对这些常用模式的理解。本文算是这次温故的手记了。 Read More

http://www-128.ibm.com/developerworks/library/j-aopwork1http://www-128.ibm.com/developerworks/library/j-aopwork2http://www-128.ibm.com/developerworks/library/j-aopwork3http://www-128.ibm.com/developer... Read More

本文向大家share一个基于AjaxHelper和Asp的企业门户构架。文中的示例本来是为朋友做的一个企业门户的基本构架，但是，人家比较传统，对Ajax可能不一定能接受，所以，最后还是改成传统的有刷新的方式了。既然之前的Ajax方案没有被采用，那就share给大家好了。本方案并没有原封不动的使用AjaxHelper，而是在AjaxHelper Flat Version 0.6的基础上作了很小的修改... Read More

看到不少朋友最近在写使用callback的文章，也有点手痒，也来涂鸦一下，挖掘挖掘callback的潜力。callback的一般使用方法还算简单，直接参照msdn的帮助和范例就足够了。但是想要真正用好、用精，或者想开发一些基于callback机制的WEB组件，那么，就要先深入了解callback的实现机制了。在本文中，Teddy将和您一起解析callback的整个调用、反馈机制，相信对于帮助您更好的使用callback，将能有一定的益处。 Read More

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

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

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