『Asp.Net 组件』Asp.Net 服务器组件 的开发优势和劣势
在写《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源码在线阅读