Session指的是访问者从开始访问一个web站点到离开为止的那段时间，而web服务器为每个访问者单独保存一个session对象。通过session可以来存储访问者的一些喜好，例如：访问者是喜好新闻还是专题文章？访问者是否喜欢下载音乐等等，这些信息都可以依据session来跟踪。Session还可以创建电子商务站点的物流篮。无论什么时候用户在网站中选择了一种产品，那么这种产品就会进入购物篮，当准备离开时，就可以立即进行所选择产品的订购。另外，session还可以用来跟踪访问者的习惯，可以跟踪访问者从一个页面到另一个页面，对于站点的更新和定位是非常有好处的。

在PHP中，允许程序设计者将常用的流程或者变量等元素组成一个固定的格式，也就是说使用者可以自行组合函数或者对象。PHP中的函数和C语言一样，包括有返回值和无返回值的，不想PASCAL分成函数和程序那么复杂。在函数的名称上，PHP对于大小写的要求很松散。可以再定义函数时写成大写的名字，而在使用时使用小写的名字。对函数而言，不用管大小写，只要主要名称没有重复就可以了。在使用时，在自定义的函数名称前要加入function的保留字，表示这是定义使用者的自定义函数。之后的myfunc可以是任何的英文字母开头的字符串，字符串除了开头不能是字符串或下划线外，在第一个字母后可以是数字或下划线，当然其他的符号或者中文字不能当函数名。

ASP是一种开发web应用程序的强大技术，但它不具备强大的工具支持，而这就无法提高web应用程序的开发效率。对大多数使用ASP的人来说，Notepad是他们的编辑器，而htm = htm&则是首选的调试方法。公平的说，Visual Interdev也是一个不错的编辑器，而且使用它时，其调试支持也相当好。但是，如果两个开发小组中有几个人在使用Visual Interdev的话，可以肯定的说，这对开发人员来说绝对不是一件好事。之所以Visual Interdev不受欢迎，是因为它对于从ASP网页到COM组件或反过来的调试支持得并不好。

ASP是使用Active Scripting建立的，Active Scripting是这样的一个技术，它最初设计用于使网站建设开发人员能够以一种统一的方式来编写和控制应用程序。它不是一种真正设计用来编写完整应用程序的技术，而编写完整的应用程序正是开发人员努力使用ASP的根本目的所在，这也就解释了为什么ASP.NET不使用Active Scripting来编写。

Active Scripting有许多固有的问题：代码是经过解释而不是经过编译的、它有一个较差的类型系统、它支持方法的后期绑定调用、每个动态脚本引擎的案例都要消耗内存等。作为一个ASP开发人员，可能早就意识到这些问题，并且在开发或初步设计自己的应用程序时也碰到过这些问题。解释代码只能导致很平庸的性能。一个不好的类型系统只会让代码更加难以开发、阅读和调试。而后期绑定代码要比早期绑定代码慢许多倍，并且会限制所能使用的组件。可能我们编写了大量COM组件来解决这些问题，但即使是这种解决办法也隐含地存在性能和维护上的问题。而且从ASP中创建COM对象本身就代价相对较大，同时如今升级COM组件通常意味着要停止web服务器。

VBScript可以被用来自动地完成重复性的Windows操作系统任务。在Windows操作系统中，VBScript可以在WSH的范围内运行。Windows操作系统可以自动辨认和执行*.VBS和*.WSF两种文件格式，此外 Internet Explorer可以执行HTA和CHM文件格式。VBS和WSF文件完全是文字式的，它们只能通过少数几种对话窗口与用户通讯。HTA和CHM文件使用HTML格式，它们的程序码可以像HTML一样被编辑和检查。在WSF、HTA和CHM文件中VBScript和JavaScript的程序码可以任意混合。

ASP.NET的新模式基于将web表单中的可视部分（HTML代码）从逻辑部分（可执行代码）中分割出来这一事实。因此，和对传统的页面的操作比起来，Web Forms的操作与VB表单以前的工作方式更加接近。同时，在使用基于浏览器的执行引擎提供一种与今天的Windows应用程序相似的用户经验方面，Web Forms有于助我们解决在开发中遇到的一些问题。

Web Forms提供多功能用户接口，同时在多种不同平台上提供这些用户接口，可以使开发人员不去考虑所使用的实际的客户端程序，因此他们可以专注于提供必要的业务逻辑。如何将客户端一服务器应用程序（这种程序的代码在两个不同的地方执行）合并为一个更加传统的事件驱动编程模型，Web Forms解决此问题的方法是提供一种单独的方法论来处理应用程序事件——而不管事件是在客户端还是在服务器上被激发的。

目前在一台web服务器上部署一个ASP应用程序可不是一件轻松的事情，特别是如果该应用程雪由COM组件组成，而且要求对IIS元数据的配置做出修改的话，问题就变得更加复杂了。我们必须将ASP文件复制到每个服务器中，复制并注册COM组件，创建COM+应用程序，并注册相关联的COM+组件，还要根据配置要求来使用ADSI更新IIS元数据。这种安装工作不是轻易就能完成的，通常需要一位操作熟练的系统管理员，同时还需要时间和耐心，这才能保证程序顺利安装和运行，否则就需要一个很高级的安装开发人员。

ASP.NET应用程序的部署就变得非常简单了，ASP.NET之所以能解决这个问题是因为对我们开发web应用程序的方法进行了几项修改。为了简化现有应用程序的重新部署，ASP.NET使用了CLR的Shadow Copy功能来确保组件文件不会被锁定。这样就从根本上杜绝了IIS部署和计算机重启情况的发生，该功能意味着在任何时候都可以简单复制新的组件重写老组件文件来及时地进行组件升级。CLR的Shadow Copy功能之所以如此，是因为组件文件在被加载之前先被复制到了某个高速缓存区域。这也就表明原来的文件不会从最初的位置进行加载了。CLR的Shadow Copy功能是在一个应用程序域的基础上实现的。系统为每个应用程序域进行了潜复制，一旦某个组件发生了变化，为了重新加载该组件，ASP.NET会创建一个新的应用程序域，这样可确保修改后的文件能够被复制到高速缓存中并继续使用它。

就像在所有动态web生成系统中那样，这里始终存在一个分工的情况。就是说服务器完成一部分工作，而客户端则完成另一部分工作。其中客户端负责给出信息和从用户那里获取信息，同时有选择地执行某个客户端脚本。而服务器则负责动态创建页面，并把页面传递给客户端。另外服务器也可以为客户端管理某个等级的服务器端状态，以便于将有关客户端任务的信息从某个用户发出的一个请求传递到同一用户发出的另一个请求中。在这种分工中，必须认识到一点，即在客户端执行的工作通常只在客户端中可见，而在服务器上执行的工作则只在服务器中可见。利用ASP.NET中得Web Forms模型，microsoft引入了服务器控件的一个新概念，即这些控件的工作原理类似于以前我们在VB中所使用的客户端控件，但他们都是在服务器上执行的。这表明客户端无法有计划地访问这些控件。

如果我们已经了解到了.NET Framework中所使用的关系型数据访问和XML数据访问这两种技术（尽管现在所了解的还只是相当基础的方法），那么我们将如何去选择数据存储方法呢？最简单的答案是有了.NET，我们无需再考虑这类事情了。

几年前，数据存储和访问技术中的主要指令还是那些构造巨大的数据保管机构和数据仓库的管理命令，我们所建立的数据都被存储在一大块中央数据库中。尽管这种方案仍然使用于某些场所，如政府的税务局，但是，当今分布式的计算环境日益清晰地表明这不是一种理想的方案。

当我们从客户端/服务器模型转换至n层应用程序模型时又出现处理非连接数据的另一个问题。分布式的环境意味着客户端和服务器在网络上是由网络分离和连接的。要在这种环境下创建能正常工作的应用程序，我们需要采用新的设计方案，在应用程序的各层次之间进行更细微的区分。

例如，在应用程序（数据层）中我们经常要创建组件来执行数据访问操作，而不是通过ASP代码直接访问数据存储。通常还要遵循一系列的规则。这些规则也能在组件内部执行。它们可能是执行数据访问操作的部分组件，也可能是单独的组件，是它们构成了业务层（或者是应用程序层）。它们可以是客户端应用程序（表示层）中的一套单独的组件，用以执行数据管理、格式设置或表示数据等特定的任务。