前言
首先要告诉大家，文章标题是我“恶意删改”了，原本是《从熟练的ASP程序员到熟练的ASP.NET程序员》。
从ASP迁移到ASP.NET的程序员肯定不少，我就是其中一个，然而要从熟练的ASP程序员转变为熟练的ASP.NET程序员并不容易，这不仅仅要求你学习非常多的新东西，还要求你丢弃非常多的旧东西。对于没学过ASP的人来说，或许这还容易些，因为他们本来就做好了苦学的准备，也没多少需要丢弃；对于熟练的ASP程序员来说则比较痛苦了，因为原本期望自己原来的知识都可以平滑过渡轻松用上ASP.NET，结果发现现实与期望的差距是那么的大。
在发现这个差距之后，没有人应该停下来然后倒退回去ASP的时代，知难而上把ASP.NET用到和ASP一样熟练才是我们的目标，因此才有了这个系列的文章。在系列的第一篇里，我们先来讨论ASP程序员缺了什么，什么是应该优先补上的，只有把这些知识补上了，我们才能够把自己称作ASP.NET程序员。
Web Standards / Web标准
做Web应用首先要懂做Web，现在提倡的是Web Standards，其所涉及的XHTML、CSS、JavaScript是一定要懂的。很多ASP程序员可能已经熟悉老式的表格排版方式，但这是应该被丢弃的东西。很多宣扬Web Standards的文章都给出了不少表格排版的坏处，那些我就不多说了，我要说的是不使用Web Standards对ASP.NET程序员最致命的一个坏处。由于MS也向Web Standards靠拢了，所以ASP.NET 2.0被设计为兼容Web Standards的，这时候所有的控件都被设计为语义与表现分离。如果你不遵守此分离规则去分工，那么随着你和你的美工轮流编织这张Web，最终有一天这张Web就会把你和你的美工给绑死。
要学好XHTML+CSS的设计，不仅仅需要观念上的转变，还需要开发工具上的更换。很多人无法适应Web Standards的设计观念，是因为他们还在用老工具，于是总是觉得用旧观念设计更方便效果更好。因为我相信，只有当你适应了新的工具，体验到新工具带来的便利和高效，你才会乐意接受观念上的转变。
说到开发工具，我假设熟练的ASP程序员都能够完全脱离WYSIWYG的编辑器而以纯文本方式编写XHTML和CSS，因为XHTML+CSS的开发要求你和你的美工都具有这样的能力。以往美工可以安乐地对着Photoshop，这是他们最习惯使用的工具，操作起来有精确性的同时又可视化，他们可能有一半的时间是用眼睛思考的。然而现在改用CSS就没这样的好事情了，能够好像Photoshop那样设计CSS的软件还没有诞生，修改任何一条CSS规则都会应用到所有页面上，至于每一个页面哪些元素会匹配这条CSS规则这需要美工用脑袋记着，不再是可视化。虽然改一下CSS规则然后看一下几个页面的预览这也是一种选择，然而这比Photoshop中调整参数时的即时预览要差多了，所以让美工学会在脑袋里进行预览是很重要的，这样才能写出好的CSS来。
如果要推荐一些工具的话，我会选择Visual Studio 2005 + Expression Web Beta 1，前者开发人员自己用，后者是美工用来设计或修改Web页面用的。
OOP / 面向对象程序设计
OOP可以说是ASP.NET的基础，没有OOP就没有ASP.NET控件这个概念，也就没有了ASP.NET与ASP最巨大的差别。
从最原始的CGI开始，Web应用开发者无非就在设计着这样一种逻辑——根据输入的Request生成输出的Response，大多数情况下两者都是平板的纯文本字符串，除非设计上传/下载文件。ASP引入了Request和Response对象，让处理稍微显得立体了一些，你不再需要手动分析Request文本，它能够帮你将提交上来的Form、QueryString、Cookies等参数提取出来供你使用。Session和Application对象的引入让你在不了解细节的情况下进行特定目的的存储，Server对象的引入则为你提供了很多有用的函数。
ASP遇到的最大问题是，立体的Request提供出来的数据却是平板的，整个处理过程也是平板的。那就说，在处理过程中的任何一个步骤，都可以访问任何一个Request数据项，然后把结果输出到Response中，这导致程序代码的耦合度很高。如果输出的Response有问题，你没办法明确指出处理过程中的哪一段应该对它负直接责任。
ASP.NET尝试通过引入控件的概念来解决这个问题。每一个控件都是一个独立的逻辑单元，它仅仅对自己内部的逻辑负责，并且尽可能减低对外部环境的依赖性。控件不再像普通的ASP逻辑那样它可以乱访问Request和Response，它的能力应该受到限制：
- 一个控件仅仅应该读取它生成的HTML元素提交回来的数据，否则应该考虑通过其他控件的属性来获取，而不是从Request获取。详细说明如下：
- IPostBackDataHandler和IPostBackEventHandler就是为控件处理自己生成的HTML有关的参数与事件而设计的。
- 如果控件要获取的数据来自子控件，则应该通过子控件的属性获取。
- 如果控件要获取的数据来自外部控件，则应该请求父控件或环境帮忙获取。
- 一个控件生成的HTML应该是环境无关的，也就是无论其他控件生成怎样的HTML都不会和此控件生成的HTML冲突。详细说明如下：
- Render用于生成本控件的HTML。
- 如果控件要生成的HTML存在可能引起冲突的情况，则应该请求父控件或环境处理。例如最常见的生成脚本，为了避免同一段脚本多次输出就应该向ClientScriptManager注册脚本，然后让它来觉得脚本的输出。
当然，上面这些规则你喜欢怎么违反都行，没有人规定你一定要这样做的。但只有遵守了这些规定，你才算得上是一个ASP.NET程序员，否则就仅仅是一个使用着ASP.NET框架的ASP程序员。
要遵守这些规则，首先要把OOP学好，这样你才会明白为什么要遵守以及如何去遵守。因为规则是死的，而我们面对的情况可能是灵活多变的，当面对一个新的情形时应该选择如何设计呢？显然你不一定能够从上面的规则中找到一条来参考，这时候你的OOP思想及价值观就起决定性作用了。
HTTP协议
HTTP协议其实没什么好说的，一个熟练的ASP程序员必须懂的东西，而且可能从你学习ASP的那天起它就没改变过。只不过对于ASP程序员来说，这东西是透明的，因为我们直接使用Request，这和直接处理HTTP协议没太大的区别。但是到了ASP.NET，Request已经被隐藏起来了，你应该避免使用它，这时候你就需要重视HTTP协议了，否则底层通讯发生了什么你完全不知道。
总结
虽然看起来我只列了3个学习要点，但我们的目标是熟练，所以每一样你都至少用上一年半载才算学到点东西，这一点儿都不简单。
本系列的下一篇将讨论“忘记什么”，如果你明白了“学习什么”，却发现学习进度不理想，那就证明你有些包袱没有抛下了。
没有评论:
发表评论