ASP.NET与WEB开发相关思想

本人目前对asp.net很有兴趣，在这里我只想着重谈三个方面的问题：

ASP.NET技术的学习顺序问题,主流Web架构的开发现状与未来展望,关于Web开发的个人疑惑。

一、ASP.NET技术的学习顺序问题

     这是本人用了很久的时间baidu出来的。

原文：

前前后后收到过一些人的来信，询问ASP.NET的学习顺序问题，在此就向打算系统学习ASP.NET技术的初学者谈谈我的建议。

　　准备：如果你已经有较多的面向对象开发经验，跳过以下这两步：

　　第一步　掌握一门.NET面向对象语言，C＃或VB.NET。

　　我强烈反对在没系统学过一门面向对象（OO）语言的前提下去学ASP.NET。 ASP.NET是一个全面向对象的技术，不懂OO，那绝对学不下去！

　　第二步　对.NET Framework类库有一定的了解

　　可以通过开发Windows Form应用程序来学习.NET Framework。ASP.NET是建构在.NET Framework之上的技术，你对.NET Framework了解得越深，学习ASP.NET就越快。

　　举个例子：下面简单列出几个对掌握ASP.NET非常重要的概念：

　　对象的内存模型，委托，事件，多线程，程序集和应用程序域，安全模型，.NET Framework当然还有许多其它的东西，但不理解与把握清楚上述这些东西，是很难真正把握ASP.NET的。

　　出于急迫的心情与现实的考虑，不少人没有扎实的面向对象基础就想直接学习ASP.NET，其结果只能是欲速则不达。

　　在具备了OO基础之后，以下是具体的学习ASP.NET技术步骤。

　　第一步：学习HTML与CSS

　　这并不需要去学一大堆的诸如Dreamweaver，Firework之类的各种网页设计工具，关键是理解HTML网页嵌套的block结构与CSS的box模型。许多ASP.NET控件最后都必须转化为HTML。而且，div+CSS是当前主流的网页布局模型。

　　学习这部分时，关键在于理解概念，而不需要将精力花在美化页面的许多技巧上，那是网站美工的工作，不是程序员的工作。

　　第二步：学习JavaScript。

　　JavaScript不是Java，它主要运行于浏览器端。可以完成许多工作，功能也很强大：比如它将客户端网页中的HTML元素看成一棵树，可以编写代码访问并修改树节点，动态生成新的HTML代码，从而达到动态修改网页显示特性的目的。

　　JavaScript在目前的网站开发中用得很多，非常重要。

　　另外，它也是目前非常流行的AJAX技术的基础。

　　第三步：学习计算机网络原理

　　找一本大学＜计算机网络＞教材，重点看看它的有关互联网的部分，了解一些域名解析和HTTP协议等知识。这是进行互联网开发的理论基础。

　　第四步：学习ASP.NET表示层技术，会设计Web页面

　　需要结合先前打好的面向对象技术的基础，至少掌握以下内容：

　　（1）各种Web控件的使用方法，

　　（2）理解信息在网页中的传送方式，比如Cookie，ViewState，Session等的使用。

　　（3）ASP.NET应用程序与网页的生命周期，以及相关对象（比如httpcontext，response，request）的用途。

　　（4）ASP.NET实现事件驱动的内幕

　　（5）自定义用户控件

　　再次强调一下，没有OO基础，很难掌握上述技术，就只能被这些东东牵着鼻子走了，会很被动。

　　第五步　掌握数据库技术

　　具体地说，要学习以下内容：

　　（1）学会使用SQL　Server 2005：不要求精通它的各种工具与管理配置技术，但至少知道如何连接，如何建表，如何创建存储过程。

　　（2）学习ADO.NET，掌握使用代码人工访问数据库（别用VS2005的向导）的方法。

　　（3）学习数据绑定控件的使用。

　　第六步　理解多层架构

　　这时，先前在OO学习阶段涉及到的程序集与应用程序域等就派上用场了，现在，网站架构大多采用多层架构：表示层、业务逻辑层、数据存取层以及数据库本身。

　　可以先上网找一此多层架构的资料看，再找一个现成的比较复杂的开源ASP.NET项目分析一下其架构就差不多了。基本上都是一个套路，到处应用。

　　有的朋友问：学习架构是不是必须学习设计模式。

　　我的看法是：不必！当然，你如果学习过设计模式，那当然更好。但在实际开发中，如果只想着机械地套用某种模式，反而起不到好的结果。我的观点：在学习设计模式时要多思多悟，其思想就会渐渐地融入你的大脑，在真实的设计实践中，忘掉所有的写在书上的模式，一切从实际出发，相信你的直觉，只要达到设计要求的方案就是可行的方案，事实上，你这样做了之后，回过头来再看，会发现你的设计往往暗合设计模式的理论。

　　 第七步　学习XML与Web Service

　　先了解XML的基础知识，找本讲XML的书看一下就差不多了，然后，再学习Web Service。Web Service其实可类比为远程方法调用（以XML格式表达的调用信息）。

　　学到了这里，如果你还有兴趣，不妨再去看看SOA，不过SOA的资料都是理论与概念，看起来比较郁闷，而且离实际开发可能比较远。所以，这是可选项。

　　第八步　学习AJAX

　　学习AJAX的主要目的是创建具有更丰富特性的Web表示层，而经过前面七步的学习，到此再学习AJAX已水到渠成，所有的基础都已具备，不会有太大的问题了。

　　在基础未具备的前提下直接学AJAX，就象“浮沙之上筑高台”，所以，将AJAX的学习次序安排在这里。

　　 第九步　学习RIA技术

　　RIA：Rich internet application，可看成是将C/S与B/S优点合二为一的尝试。就具体技术来说，主要指微软的Silverlight（WPF_E），毕竟前头一路行来都是微软路线。

　　不过目前学习它主要是为了技术储备。估计此技术的普及需要2到3年的时间，因为预装Vista的机器今年才开始大卖。

   二、主流Web架构的开发现状与未来展望   

     在前面我们了解了学习ASP.NET的方法，下面我们来看看什么是Web开发，Web架构,以及有哪些主流的架构。

   Web开发，就是通过Web前端管理一个或大或小或独立或分布式的关系型数据库，很多东西都是相通的。

   Web架构，是指Web应用开发中每种技术独有的资源组织形式（包括文件，数据库，HTTP请求处理等。），也许说开发方式更容易让人理解一些。

   Web程序的架构基本上可以分成以下三类：

     (一) 基于“Web页面/文件”，例如CGI和PHP/ASP程序。

     程序的文件分别存储在不同的目录里，与URL相对应。

当HTTP请求提交至服务器时，URL直接指向某个文件，然后由该文件来处理请求，并返回响应结果。 比如http://www.hexun.com/news/readnews.php?id=1234 可以想像，我们在站点根目录的news目录下放置一个readnews.php文件。

    这种开发方式最自然，最易理解，也是PHP最常用的方式。要注意产生的URL对搜索引擎不友好，不过你可以用服务器提供的URL重写方案来处理，例如Apache的mod_rewrite。

　　 (二) 基于“动作”(Action)。这是MVC架构的Web程序所采用的最常见的方式。目前主流的Web框架像Struts、Webwork(Java)，Ruby on Rails(Ruby),Zend Framework(PHP)等都采用这种设计。URL映射到控制器(controller)和控制器中的动作(action)，由action来处理请求并输出响应结果。这种设计和上面的基于文件的方式一样，都是请求/响应驱动的方案，离不开HTTP。

比如 http://www.hexun.com/news/read/id/1234

　　 可以想像在实际代码中，我们会有一个控制器newsController，其中有一个readAction。不同框架可能默认实现方式稍有不同，有的是一个Controller一个文件，其中有多个Action，有的是每个Action一个文件。当然这些你都可以自己控制。

　　 这种方式的URL通常都很漂亮，对搜索引擎友好，因为很多框架都自带有URL重写功能。可以自由规定URL中controller、action及参数出现的位置。

　　 另外，还有更直接的基于URL的设计方案，那就是REST。通过人为规定URL的构成形式（比如Action限制成只有几种）来促进网站之间的互相访问，降低开发的复杂性，提高系统的可伸缩性。REST对于Web Services来说是一个创新。

　　 虽然本文讨论的是单个项目所采用的架构，而REST是为了解决网站之间的通讯问题，但REST的出现，会对单个项目的架构造成影响（很显然你在开发时就要构造规范的URL）。将来混用REST和MVC应该也是一种趋势。RoR提供很好的REST支持，Zend Framework也提供了Zend_Rest来支持REST，包括Server和Client。

     (三) 基于“组件”（Component ，GUI设计也常称控件）、事件驱动的架构，最常见的是微软的.NET。基本思想是把程序分成很多组件，每个组件都可以触发事件，调用特定的事件处理器来处理（比如在一个HTML按钮上设置onClick事件链接到一个PHP函数）。这种设计远离HTTP，HTTP请求完全抽象，映射到一个事件。事实上这种设计原本最常应用于传统桌面GUI程序的开发，例如Delphi，Java Swing等。所有表现层的组件比如窗口，或者HTML表单都可以由IDE来提供，我们只需要在IDE里点击或拖动鼠标就能够自动添加一个组件，并且添加一个相应的事件处理器。

这种开发方式有几个优点：

   复用性：代码高度可重用。

   易于使用，上手容易：通常只需要配置控件的属性，编写相关的事件处理函数。

   效率：这里指的不是开发效率，而是代码的执行效率。ASP .NET是编译型的框架，最后生成的代码是编译生成的，不需要再次进行中间过程的诸多处理，所以在第一次执行之后速度会很快，执行效率还是很高的。　　　

  强大的IDE支持： 大量的控件支持，设置控件的属性，添加其对应的事件处理器，看似简单，但控件多了，这也是个繁重的工作。.NET的强大就在于它把程序员从重复的工作中解放了出来，设置属性很方便，事件处理器也会自动添加。（关于这儿，请看关于Web开发的个人疑惑）

　　 总之，这种基于控件的框架比较适合于用户交互较多的，需要对页面中的很多组件设置不同处理操作，但对于性能要求不高的应用。另外，带有组件支持的框架通常对AJAX的支持都较好，比如.NET和Ruby on Rails。

　　 综上所述，三种架构基本上可以代表目前的所有主流Web开发方式，包括PHP,JavaEE,.NET,Ruby/RoR。

未来展望

　　 随着更贴近HTTP的REST的流行，我个人觉得像.NET和Java中的抽象组件的方式会受到冲击。因为这些组件并不如它们所承诺的那么方便。未来MVC+REST+RIA的模式应该会比较流行。

　　 AJAX是一把双刃剑，尽管事件驱动的架构看起来非常适合于处理异步的请求，但要为客户端自动生成良好的JavaScript代码是很不容易的，要满足各种浏览器的兼容性要求，还要能够自己进行扩展，以满足项目中千奇百怪的需求。看到这儿你可能会说，老大：你杀了我吧！其实很多时候我们可以使用一些JS框架（如Prototype）来自己开发各种效果，而不是在服务器端生成。

三、关于Web开发的个人疑惑

    在我想写这的时候，在网上看到已经有朋友想得更早了，思想都差不多，我们一起来看看：

     为了让开发更简单，我们常常不得不学习使用复杂的开发工具和框架，这到底是一个进步，还是退步？ IDE让程序员变聪明还是变傻？ 当我们在服务器代码里面就可以设计客户端界面，这是一个进步还是退步？ 举个例子来说，微软的ASP.NET AJAX，让我们可以在服务器端设计各种异步的控件。那么程序员甚至可以不会Javascript，不懂AJAX就设计出各种客户端效果。要是哪一天项目需要设计稍复杂的效果，靠IDE和框架无法自动完成，你要怎么办？　到这个时候再来学JS，也许就迟了。更可怕的是，技术在更新和淘汰，可能十年之后，你会发现自己除了各种IDE之后，真正精通的技术很少，脱离了IDE你写一个小程序都要查半天API手册，因为你平时都是依赖“自动补齐”来写代码的！ 这样的情景，我想没有人愿意发生。

   也许对于短期开发的项目来说，是一个进步，但对于程序员个人的成长来说，这并不是好事。对工具的依赖，导致了我们对于底层和核心技术的不求甚解，限制了个人的成长。还有就是在合适的地方使用合适的技术。

全文完/作者:陈绍林

如果你对以上文中的技术、观点感兴趣或持有不同态度，欢迎讨论。