下面我们谈一谈开发人员如何快速地开始ASP.NET的程序设计。
你发现ASP.NET中什么东西比ASP更吸引人？
有些人说是配置，ASP.NET配置起来更容易吗？因此，我想谈论关于这个问题的一点内容。我们的确发现ASP.NET的一个优点是可以简单地配置。由于ASP.NET的应用程序是由编译过的代码组成，所以不需要注册DLL或者停止某些服务。例如，在今天的ASP环境中，如果在你的网站上，有一个非常重要的商业组件需要被一个功能更加强大的组件替换时，你将不得不暂停WEB站点的服务，以便使得DLL不被锁定。然后替换该组件，重新在系统中注册，重新启动你的WEB站点，这样做的结果是在某一段的时间里，你的站点将不能对外工作。然而，令人兴奋的是在ASP.NET中，你不需要在做上面的任何工作，你在也不必考虑那个该死的regsrv32。你只需要将这个新的DLL放到与老的DLL系统的目录下。当前访问的新的DLL的请求仍然在工作，新的请求将会触发新的DLL,这一切会持续到老的DLL完成所有的请求时为止。那时，新的DLL就会代替老的DLL,这一切不会引发停机，这一切只需要调用XCOPY的配置功能，这一切使得我们的工作更有效率，更加简洁。
这样做的好处是不用再考虑哪个DLL需要关闭，然后再关闭它；哪个DLL中有BUG。是否有一种方式可以使得当前应用的所有的DLL迅速的被关闭，还是必须要将WEB站点停掉。
对我来说，保留它前面的版本，后面的版本是一件很容易的事情。只需要利用XCOPY重新配置一下就可以了，那些DLＬ很快会被自己替换。
好了，除了前面所见的配置简单的这个特性以外，你们还有那些优点足以吸引ＡＳＰ 程序员快速移植到ASP.NET环境中？
这个问题问得好，如果我是一个VB程序员，当我进入ASP编程环境时，我会发现，他是如此熟悉，我乐意立刻在那里编制程序。我不用担心那些脚本语言，不用再考虑那种从头到尾都是线性的处理模型，我可以在ASP.NET中使用更新的逻辑关系，使用提供的更多新服务器组件，提供比ASP程序更多的功能。
确实是这样的，ASP.NET节省了我们大量的的开发时间，你可以在同样的环境下开发供ASP+页面调用的DLL，并且可以安全的使用。然而，对大多数的开发者来讲，最大的收益来自于他提供的caching功能。
我们都理解caching功能对于标准的web页面的重要性，客户端的caching可以使得页面很快重现，服务器端的caching存储了一些已经编译过的代码，可以提访问的速度。
我们下面举一个caching的例子，一个在线的商店，这是一个销售CD的网上商店，在他的主页面上，你列举了一系列的商品。因此，你使用了数据库存储商品信息、价格信息、种类信息等。当ASP脚本访问数据库时，不可避免地会有时间延迟。但是，当你使用caching时，一些访问过的信息将会留在caching中。当请求的信息在caching之内被检索的时候，caching中的页面作为原页面输出，因此，你不必在访问数据库就可以获得数据，因为他们已经在caching中了。.NET框架会一直监视caching中的页面，如果这些页面相关的数据库的信息发生了变化，他就会立即更新这些页面。因此，你不必担心得不到最新的数据信息。通过caching的设置功能你还可以设置caching的时间长度，规定他在多长时间内定期更新caching中的内容，你也可以在caching中缓存页面的点击数。总之，通过caching技术，你实际上为你站点的用户提供了快速获得信息的可能性。在本质上，他实际上直接获取的是生成好的HTML页面，从而避免了一系列的页面生成的过程。
caching将真正帮助网站的开发人员调整网站的性能以及快速的相应客户的请求。
是的。实际上你可以看到这样的情形---网站服务器每秒钟可以相应更多的点击数，因为用户大部分的请求都落在caching中。
从开发人员的角度来看，如果他们在编写第一个ASP.NET程序时，他们会遇到哪些大的困难？
我对您的话感到吃惊，从ASP到ASP.NET并没有不可逾越的障碍。他们只是在一些细节上有所不同。当然有许多的是要引起注意的。例如，我们过去常用ASP与VB SCRIPT编写程序，当我们想创建一个record set对象的时候，我们不得不SET一个变量等于record set。在ASP.NET中没有SET这个参数，直接就是变量等于ADO records set对象。所以，在ASP与ASP.NET之间仅有一些小的语法的差异，这些小的语法差异根本不会影响到页面的性能，但是如果你将ASP程序移植到ASP.NET上时，你要注意这些小的差异。实际上，从ASP迁移到ASP.NET的代码量是很少的，不必考虑将整个程序代码移植，这两者实际上是可以并存的。因此你不必强制将你的网站的程序立即移植到ASP.NET上，你可以在新的工作中逐渐采用新的ASP.NET技术。
我想，你仍然可以像你从前那样声明你所有的数据类型。你仍然可以使用Server.CreateObject,你仍然可以使用 DIM RS，定义一个record set对象，你仍然可以使用DIM RS AS NEW ADO record set这种方式，对吗？
这只是我们的一种选择，在我们最少量的移植级别里面，你实际上不用考虑ASP 与ASP.NET的区别。你仍然可以使用 DIM RS 的方式，并且用这种方式创建与数据及相关的对象。这两者之间的主要区别是一个是用VB SCRIPT创建的对象，另一个是用VB创建的对象。
这么说，你们现在是已经改变到一种拥有类型的开发语言平台上了？
你说的很对，我们有数据类型了。我们现在更严格的进行应用程序的内存管理，而不是将每一件事情能够都看成是变量，我们现在可以将不同的事物看成string、 integer、a data set，因此我们可以更好地控制内存的使用。
接下来，我们应该演示一些代码用以解释上面所说的一些东西。
好的。我们的第一个问题是移植问题。这是一个典型的ASP代码的页面，我们将从数据库中取出数据放到表中。我们来看一下这些代码，我们首先定义了我们的connection 和我们的 record set， 我们创建了这些对象，我们用SET关键字设置我们的record set 等于connection的执行。接下来是一个DO WHILE 循环，将数据库中的信息显示在页面上。
<%
Dim con, rs
Set con = Server.CreateObject("ADODB.Connection")
con.Open "Provider=SQLOLEDB;server=(local);database=Northwind;UID=sa;PWD=;"
Set rs = con.Execute("SELECT ContactName, City FROM Customers")
%>
<html>
<body>
<table border="0">
<tr>
<td>ContactName</td>
<td>City</td>
</tr>
<%
Do While Not rs.EOF
%>
<tr>
<td><%=rs("ContactName")%></td>
<td><%=rs("City")%></td>
</tr>
<%
rs.MoveNext
Loop
%>
</table>
</body>
</html>
如果转到.NET框架下，仅需要少量的移植工作。我们可以看见哪些东西已经被改变了，哪些东西不能使用了。我们在Set con = Server.CreateObject("ADODB.Connection")和Set rs = con.Execute("SELECT ContactName, City FROM Customers")中所使用的set之类的关键字一去不复返了。但是在这里我要指出的是，在下面的代码中，我们在rs("ContactName")和rs("City")的右边添加了一个属性Value。他的基本含义是，我们可以获得指定行或者指定列的值。从ASP到ASP.NET也就这些改动，实际上有很少的变化，你可以看到ASP与ASP.NET代码之间几乎一样，没有什么特别大的变化。
<%
Dim con, rs
con = Server.CreateObject("ADODB.Connection")
con.Open("Provider=SQLOLEDB;server=(local);database=Northwind;UID=sa;PWD=;")
rs = con.Execute("SELECT ContactName, City FROM Customers")
%>
<html>
<body>
<table border="0">
<tr>
<td>ContactName</td>
<td>City</td>
</tr>
<%
Do While Not rs.EOF
%>
<tr>
<td><%=rs("ContactName").Value%></td>
<td><%=rs("City").Value%></td>
</tr>
<%
rs.MoveNext
Loop
%>
</table>
</body>
</html>
这是很吸引人的，那些SET关键字被去掉了，VALUE关键字被引入，代码本身实际上没有什么变化，因此只要你看看输出结果，你就会发现他们基本上是一致的。但是，ASP.NET是运行在.NET框架下，他的页面扩展名是.ASPX，当然我们在该页面也可以实现CACHE的功能，只不过在这个程序中没有用到罢了。如果我们将上面的实例进一步深入下去并且考虑应用.NET框架和ASP.NET框架所提供的一些更为便利的手段。例如，用managed providers来获取数据，那么我们将以入下面这个事例。我们依然工作在SQL 7.0上的NorthWind数据库中。
.ＮＥＴ提供了一个重要手段是SQL managed provide，它可以直接连接到SQL上获得数据而不必通过OLEDB这样的东西，这种方式经过实践被认定是大大提高了访问速度。我们可以看一下下面的代码,他们使用纯粹的VB而不是VBs编写的。但是输出的结果几乎一样读。我们要做的事情是import 一些namespaces , System.Data，这样我们就会有最基本的数据处理能力以及获得对SQL managed provider访问能力的 SQL namespace。这些代码的风格与前面讨论的C#的风格好象很一样，那时我们使用C#来处理基于.ＮＥＴ架构的各种类库，现在我们所见到的在VB中的.NET类库与C#中的类库具有相同的风格。
这两者之间的确是同一种风格。如果我用C#编写，代码会不同，但是namespace（名字空间）是一致的。对于编写ASP.NET的程序，这两种方法都是很好的。尽管某些类可能会有一些不同，但是我们可以仅仅修改几个的地方，就可以将VB代码快速移植成C#代码。
实际上，许多代码将不会被改变（一直保留下来）。例如，SQL connection 字符串只需要改变一点点， SQL select statement 字符串不会有什么改变。在这里，我们强调一下，对于connection 字符串我们不再使用 ADO provider，不再使用SQL OLEDB作为ADO provider,因为我们使用了SQL managed provider，因此我们提倡使用SQL7.0以上的版本，他能给我们更好的性能。我们创建一个data set用以保存我们的数据以及后来访问的结果。我们用SQLDataSetCommand检索SELECT的结果，并返回页面，将他们插入到data set中，我们命名这个表为Customers。因此，我们现在有一个data set对象，他包含了一个Customers表。如果需要的话，我们可以加入更多的表和更多的关系。与ADO records set不同的是，我们现在可以处理更大的事情，我们可以将整张大表分成若干个小表，而他们之间的关系去保持不变，这种方式有利于更大的程序应用开发。.
<head>
<script runat="server">
Sub Page_Load(Source As Object, E As EventArgs)
Dim ds As New DataSet
Dim dsc As SQLDataSetCommand
dsc = New SQLDataSetCommand("SELECT ContactName, City FROM Customers", _
"server=localhost;database=Northwind;UID=sa;PWD=;")
dsc.FillDataSet(ds, "Customers")
dgCustomers.DataSource = ds.Tables("Customers").DefaultView
dgCustomers.DataBind()
End Sub
</script>
</head>
.
接下来，我们跳过几行代码，直接显示与ASP data grid server控件相关的代码。ASP data grid server的作用是提供一个最基本的表。我们要做的唯一的一件事情是告诉他我们要在服务器端运行他，他是服务器端的控件。接下来我们设置the border宽度为零 ，因为上面的例子中border="0"。此外，我们新加了一个属性，他用来改变items的背景色。他用来标识在ASP表中不同表格项的颜色，这样便于区分。当然，你要写很多的代码，用循环的方式改变每一个项目的背景色，在这里我们简化一下工作，只是标志这个属性。他表现的色彩是浅灰色。
<body>
<asp:DataGrid id="dgCustomers" runat="server"
AlternatingItemStyle-BackColor="#CCCCCC"
BorderWidth="0"
/>
</body>
</html>
……