2006年11月9日星期四

从 ASP 到 ASP.NET (Part 1 - 学习什么)

前言

首先要告诉大家,文章标题是我“恶意删改”了,原本是《从熟练的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个学习要点,但我们的目标是熟练,所以每一样你都至少用上一年半载才算学到点东西,这一点儿都不简单。

本系列的下一篇将讨论“忘记什么”,如果你明白了“学习什么”,却发现学习进度不理想,那就证明你有些包袱没有抛下了。

没有评论:

发表评论