在写《Asp.Net 服务器组件系列文档》之前，笔者不才，揣测微软战略用意：
微软利益诉求莫过于 微软产品和技术的市场份额；
因此，微软战略之一莫过于将 所有开发人员 团聚在 微软周围，以推动微软技术更新，微软系统的推广；
因此，就有了 简化编程（比如 C#的诞生），网罗开发人员（跨语言的.Net平台）等相关举动；
而 微软的“所见即所得”（VS开发工具中 WinForm，Asp.Net，Silverlight 等 都支持这里理念）编程理念，则将开发人员的门槛降低了不少；
简而言之：微软的技术取向上：让开发人员简单编程才是第一位，微软技术的执行性能可能才只是第二位或更往后；
项目开发中，技术选择的矛盾：
一家公司，同一个业务功能：
让一个四年工作经验的人写 100行代码；
或者让一个应届毕业生 基于某个技术，写2行代码（但是性能只有前者的 80%）；
问，这家公司将作何选择？
前者：
性能很快，代码流畅整洁；
项目测试或交付，发现BUG，100行代码内阅读代码，修改代码；
人力有限，修复BUG可能交给一些能力相对差点的人，于是 可能代码风格不一致，技术能力不一致，修复BUG时，又带入新的BUG；
类似的BUG也要修改，实际修改代码行数 取决于 这 100行代码如何复用；
最终可能出现：代码增加到 150行，修改BUG之后，性能降低，可能引入新的BUG；
后者：
性能只有前者80%，代码流畅简洁；
项目测试或交付，发现BUG，2行代码内阅读代码，修改代码；
人力有限，另选一个应届毕业生修改，依然2行代码，顶多5行；
类似的BUG，搜索一下 相关技术关键字，修改 5*N 行代码；如果是技术BUG，只用修改技术代码；
最终可能出现：代码增加致 5行，性能还是那个性能，很难引入新的致命BUG——代码少，BUG就少；
做过大项目的人或许都体验过 被人追着 改BUG 的情景：
情况紧急 或者 能力不足，保不准就 先贴个狗皮膏药应付BUG；
等到想起 要将狗皮膏药修改成正规代码时，自己又忙的不可开支，没时间改——只要不报错，管他代码是否规范；
因此，我也看到过某些项目完成的时候代码很漂亮，但是最后测试或交付之后，代码就惨不忍睹了。
本文当适合人群，不适合人群请自觉绕行：
如果你在 上面的公司技术的选择中，选择了前者， 本系列文档 不适合你。
如果你 在项目中，排斥反射机制 等技术，是一个 性能挑剔派，本系列文档 不适合你。
Asp.Net 服务器组件的 优缺点：
优点：
开发者门槛低；
VS中，所见即所得，不得就直接报错，扼杀错误于摇篮；
技术封装；
缺点：
性能损失 20%-50%；
技术BUG将导致批量错误；
当然，欢迎补充….
至此，让我们开始 Asp.Net 服务器组件的编程之旅吧…..
相关系列文章链接：
『Asp.Net 组件』Asp.Net 服务器组件 的开发优势和劣势
『Asp.Net 组件』第一个 Asp.Net 服务器组件：自己的文本框控件
『Asp.Net 组件』Asp.Net 服务器组件 内嵌图片：自己的图片控件
『Asp.Net 组件』Asp.Net 服务器组件 内嵌CSS：将CSS封装到程序集中
『Asp.Net 组件』Asp.Net 服务器组件 内嵌JS：让自己的控件动起来
『Asp.Net 组件』Demo源码在线阅读
