自2000年6月Microsoft公司发布.NET计划以来，使编程工作在业界中引起了一次划时代的革命。ASP.NET是.NET计划中的一个重要组成部分，其为Web应用程序开发人员提供了许多新特性，这些特性包括已编译的服务器端代码、一种将服务器端逻辑与客户端布局相分离的代码隐藏（code-behind）技术、可扩展的服务器端控件模型、设计数据绑定模型、xcopy部署以及客户和服务器上的窗体身份证验证支持等。
ASP.NET作为一种先进的Web应用程序开发技术，相对于ASP具有革命性的进步。其使用编译后的语言（包括元数据、IL等资源），这是.aspx文件运行性能大大提升的一个主要原因，也是ASP.NET不同于以往的ASP的显著地方。ASP.NET第一次装载页面的速度较慢，但以后加载该页面的速度是ASP不能比拟的，其速度飞快。这是因为ASP.NET在第一次访问网页时所需要开销有：加载ASP.NET工作者进程，对.aspx 文件进行语法分析并将其编译成一个可执行的程序集。这一点与ASP引擎执行服务器代码是不同的，因为ASP总是每次执行时都是将服务器代码交给Jscript或VBScript解释器来进行解析。
ASP.NET在技术上没有叫做ASP 4.0，但从许多方面来讲，它就是ASP 4.0版本。我们可以从下面的两个例子看出.aspx文件与.asp文件的相似之处：
例程1：ASPX页面示例
<!--File:test.aspx-->
<%@ Page language=’C#’ %>
<script runat=server>
int Add(int x, int y)
{
return x y;
}
</script>
<html>
<body>
<table border=1>
<tr>
<td>两数之和为：</td><td><%=Add(2,3)%></td>
</tr>
</table>
</body>
</html>
例程2：ASP页面示例
<!--File:test.asp-->
<%@ language=Jscript%>
<script language=’JScript’ runat=server>
function Add(x,y)
{
return x y;
}
</script>
<html>
<body>
<table border=1>
<tr>
<td>两数之和为：</td><td><%=Add(2,3)%></td>
</tr>
</table>
</body>
</html>
以上两个例程的<html></html>里的代码是相同的，不同的是 <%%>声明使用的语言。两段代码都是在服务器端运行，但是，当访问这两个文件时，其背后所发生的事情却截然不同。我们先来分析test.asp文件的运行机制，当执行test.asp文件时，服务器对网页中的文本要进行线性解析，提取所有不是服务器端脚本的内容并作为响应返回，而网页中的服务器端脚本（我们在test.asp文件的脚本中加入了runat=server属性）首先要通过Jscript解释器来解析执行，执行结果作为响应返回。所以，.ASP文件的运行机制在几个方面影响了网页生成（也就是我们平时所说的程序运行）速度变慢。影响.ASP网页效率的几个方面是：首先，随机解释服务器端脚本比在服务器上执行预编译的代码效率更低，因此，要对ASP应用程序进行优化，比较通用的方法就是将大量的服务器端脚本移入预编译的COM组件中，这样就可以有效的提高网页的响应速度；第一的方面是，由于要不断地调用解释器，混合使用静态的HTML和服务器端求值语句脚本块比只用一个服务器端脚本块的效率更低，因此，为了提高应用程序的执行效率，有些ASP开发人员通常使用Response.Write()调用取代静态的HTML元素。最终导致了一个ASP页面上使用多种脚本语言来编写从而大大降低了应用程序的执行效率。现在，我们再来分析一下test.aspx文件的运行机制，在该例中使用c#语言来编写的脚本，所以在服务器端CLR使用相应的C#编译器把这些代码编译成一种叫做IL汇编语言并保存到程序集中。使用CLR，无论你使用何种语言（C#、VB.NET、Jscript 等）编写的脚本，最终都被编译成IL汇编语言。程序集的生成过程如下图所示：
由上图可以看出，程序集中既包括服务器端代码又包括静态HTML语句，因此，只要第一次访问了某个.ASPX页面，以后生成该页面时只需执行已编译好的代码即可。就是ASP.NET网页最终都被编译成.NET类（.NET框架中组件也叫做类），所以，在一个.aspx文件中不可能使用多种服务器端语言，这样就解决了传统的ASP脚本模型的所有有关效率低的问题。所以说，ASP.NET是ASP的升级版本。
与解释模型相比，使用编译模型还有其他方面的好处：
1、在性能方面编译模型优于解释模型。因为，编译器将网页编译成类（组件），这样就可以用桌面应用程序或组件开发者使用的同样的调试工具进行调试。
2、便于应用程序在编译时可以发现错误，这样就可以使应用程序的健壮性大大增强。
3、.NET应用程序开发者可以使用的所有工具，.aspx开发者同样可以使用。
总而言之，从传统的ASP过度到ASP.NET，是在程序的性能、速度等方面的革命性的改进。
从ASP过渡到ASP.net遗留的二十大积习
在技术更新的进程中, 仍然有一些人死抱着已经过了气的东西不放. 也有一些人虽然进入到新的世界, 但仍摆脱不了陈旧的习惯. 我没有用”陋习”这个词, 因为我对这个词也非常反感.
新技术应该有新技术的做法, 进入ASP.NET的世界, 就应该把以往的习惯改正, 全新的进入新的世界.
以下列举的都是错误的做法, 请不要误以为是推荐的做法而进行推广:
1. 使用server side include给ASPX引入共同的页面构图.
在ASP.NET的机制下, 应使用ASCX(web user control)来实现. ASCX提供了更多可控制接口. 并且更重要的是, ASCX是一个类. 一个实实在在的类. 可以全面控制它.
2.不使用web.config
web.config提供了非常丰富的配置管理接口. 是一个应用程序最核心的部分. 但是很多人的web.config往往是空的. 或者就从来没有修改过.
3.使用Response.Write向前端输出消息
ASP.NET平台下的Response和ASP的Response有很大的不同. 虽然表示同一含义, 但用法上已经大不相同. Response.Write的内容只会输出到页的最前端. 向前端输出消息的正确方法是使用PlaceHolder.
4.使用一系列session管理用户连接状态
这种方法在ASP里被滥用. 在ASP.NET环境下, 正确的做法应该是设计一个类. 结构化地保存数据. 将对session或者cookie的访问封装起来.
5.使用session验证身份
这几乎是通病. ASP.NET提供了一组用于用户身份验证的API. 类型是forms验证或者windows验证. 这一点quick start有一节讲解得很清楚. 可以绝大部分人还是依靠给session赋值来保持用户身份验证状态.
6.使用Response.Redirect重定向页
这一点在必要的时候可以使用. 但不可滥用. 事实证明滥用重定向将导致逻辑上的严重混乱. 这是在以页为程序单元的时候的做法. 使用front controller模式将使用户的操作逻辑集中起来]
7.使用太多ASPX页
ASP环境下的程序单元只有*.asp页, ASP.NET可不是这样, 还有后端的类库, ASCX等等. 应将业务逻辑分别集中在不同的单元, 而不应该一项操作使用一个ASPX. 更多时候ASPX将做为ASCX或者custom control的容器而管理页内逻辑. ASPX重用ASCX的同时, ASPX也做为统一的页构图重用.
8.在多个逻辑单元之间复制代码并修改相应逻辑
重用. 重用. 重用. 处理此类问题的原则是不出现任何相同或相似的过程. 如果你用上面的方法, 一旦出现重大逻辑更改, 带来的结果将是灾难性的.
9.害怕使用DataSet.
很多人被DataSet吓坏了. 认为”肯定”影响性能. 但连最初的尝试都不敢. 他们总认为他们的产品一定重大, 设计上应该”慎重”. 他们往往使用ArrayList或者设计低级的类来保存集合数据. 进行艰难的数据倒入工作.
10.对“性能”过多注意.
对ASP.NET ViewState的机制特别不满. 或者总是挖空心思迫害人家. 反倒把自己弄得很累. 如果在对付ViewState的同时多注意少连几次数据库也许更文明些.
11.应用程序根目录很乱.
ASP.NET是开发项目. 不是网站. 应该把不同的资源分类放置. 例如把所有静态资源(样式表, 脚本, 图像)组织到一起. 甚至可以写一组API来管理他们. ASPX应该放在一起. ASCX应该放在一起. .*.cs呢? 应该把他们放到另外一个project里.
12.不厌其烦的写访问数据库的过程
应该把这工作交给DataAccess Application Block. 你自己还要开关connection, 何苦呢.
13.自己写的东西最靠得住.
事实往往正好相反. 多注意使用人家写好的产品. 又不收你钱, 何苦那么爱面子呢.
14. 胡乱命名ASPX文件名
这是最让人痛苦的了. ASPX文件名不仅需要容易识别. 还应该遵循一定规则. 因为behind每个ASPX都会有一个同名的类, 想象一下, 多难受. 另外大部分人不知道管理自己的项目的name space. 让人好像看到一本帐一样.
15.从来不作继承或派生
一些具有相同行为的类, 应该从公共的基类派生出来. 实际意义上, 我们的ASPX应该有一个基类PageBase. 因为总有一些公共的特性需要抽象出来.
16.零property
他们的类(ASPX所对应)里只有private method. 不公开自己的任何秘密. 可以这一定是JAVA的遗老干的事.
17. 零ASCX
不用说, 他还没学会ASP.NET
18.使用DreamWeaver“画“ASPX
这批人是美工. 甚至有一些人在非常陶醉地讨论如何更好地“整合“ DreamWeaver和Visual Studio.
19.只熟悉System.Web.UI.WebControl和System.Data.SqlClient应该还有一些值得熟悉的类库.
20.零注释
这些都是心里很明白的快手. 一任IDE生成的缺省注释横在那里不管.
21.零事件
对“事件驱动“一无所知. 只知道在Page_Load()里写过程. 或者双击一个按钮写Xxx_Clock()过程. 在他们的程序里看不到event和delegate.
引用本页地址：
http://www.yongfa365.com/item/ASP2ASP.net.html
