目前在一台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代码直接访问数据存储。通常还要遵循一系列的规则。这些规则也能在组件内部执行。它们可能是执行数据访问操作的部分组件，也可能是单独的组件，是它们构成了业务层（或者是应用程序层）。它们可以是客户端应用程序（表示层）中的一套单独的组件，用以执行数据管理、格式设置或表示数据等特定的任务。

事实上，很明显最重要的不是在哪里存储，（在某些情况下）也不似如何存储数据。问题的关键所在还是我们如何去访问并处理这些数据——无论它们以何种格式存放、位于何处。正如我们采用的XML并设计.NET数据访问库的原因所在。因此，在执行一个数据存储时我们要考虑哪些问题呢？而哪种数据访问技术又是最合理的呢？问题的答案更多的基于数据的特征，以及我们要以何种方式使用这些数据。例如，高度结构化的数据，如股票列表或客户的信息，适合用关系型数据库如SQL Server、Oracle或桌面系统的MS Access来存储。但是，非结构化的数据，如报表、数据表、电子邮件消息、家谱和其他一些日用信息，则更适合用XML的树状隐喻来存储。

我们已经知道如何使用SQL语句直接从数据源提取数据。而在实际的应用程序中，更好的办法是使用数据仓库中的存储过程来返回所需的数据集。这样可为用户提供一个更好的性能，同时能更好地控制访问许可，而且还有助于在那些好奇的用户面前隐藏数据仓库表的具体内容。

在传统的ADO中，.NET数据访问类能够像处理SQL语句那样轻而易举地处理存储过程。最简单的存储过程只需要我们指定过程的名称，它们就会返回一组无法由ASP代码控制的结果。不过存储过程是可写的，这样它们就可以接受参数。而这就允许由设定参数值和调用过程的ASP代码来控制所返回行集的实际内容。

使用SQLXML属性将数据从SQL Server中提取为XML的技术，对于当今的数据库开发人员来说是非常有用的，而且它特别快捷有效。要在.NET总支持SQLXML，只需要简单地包含一个选项，以此来返回一个可以保存XML文档片段的对象。该对象可以代替关系数据中所提到的DataReader对象。

这个方法实际上是用于关系数据访问的Command对象中可用的执行方法的一种特殊形式，它可以返回一个XmlReader对象。这种方法(理所当然)被称为ExecuteXmlReader。如何在页面中用代码实现该方法。首先，我们收集了来自自定义用户控件的字符串，然后创建一个可以提取XML所需的SQL语句。

一个有效的XML文档，必须遵守由W3C指定的特定的标准，特别是要“格式良好”。换句话说，要是我们的XML文档有效，必须符合以下的条件：

一、只有一个根元素，该元素包含了除文档声明以外的所有其他内容，它用于处理说明和注释。

二、所有的开始标记都有结束标记与之匹配（或者是使用一种用正斜杠符合来终止元素的简单写作语法）。

三、嵌套表格要正确，以便将元素完全包含在内。也就是说，当元素师其他元素的子元素时不能打开它，而且不能再关闭子元素之前先关闭父元素。

四、只包含有效字符。必须避免所有无效内容，或者用正确等价实体来代替，例如用&来代替&。

我们在处理DataSet和DataTable对象时，最后要考虑的问题是我们如何对列和表指定自定义的映射。当我们在DataSet中，从诸如关系数据库的数据源填充数据表时，我们可以指定DataSet中数据表的名称，作为DataAdapter对象的Fill方法的第二个参数（可选的）。如果我们不提供这些内容，那么数据表将和数据库中的源表具有相同的名称。不过在这种情况下，我们队新填充的表中列的名称没有直接控制。它们自动采用了由存储过程，表名或者填充表的SQL语句所返回的列名。

不过，同时在DataSet中指定表和列的名称是很方便的。这样，我么可以创建可重复使用的代码，它能够自动地把数据映射到正确的列和表的名称中。这样做也可以简单地调用Update方法，使对数据的改变返回到数据库中。

关于DataTable和DataView对象的问题，在网站建设编码过程中一旦我们用数据装载了DataTable或DataView对象，我们并不是真正想要返回到数据存储，而且也不是在每次我们把行分类为不同阶时再重新装载，或者筛选行以便只有行的子集被显示。值得庆幸的是，DataTable和DataView对象都具有分类的筛选功能，而他们在对象之间工作的方式是有原则上的不同的。

数据源控件提供多种数据服务，这样将高级功能添加到应用程序会变得更加容易。这包括根据指定的搜索条件筛选数据。筛选对于使用缓存数据尤其方便，因为您无需重新运行查询或调用读取数据的方法就可以提供搜索功能。