毕业设计外文翻译.doc

南京邮电大学毕业设计(论文)外文资料翻译学 院专业学生姓名班级学号外文出处附件：1.外文资料翻译译文；2.外文原文指导教师评价：1翻译内容与课题的结合度： 优 良 中 差2翻译内容的准确、流畅： 优 良 中 差3专业词汇翻译的准确性： 优 良 中 差4翻译字符数是否符合规定要求： 符合 不符合指导教师签名：年月日附件1：外文资料翻译译文非常ASP.NET1.1Web 部署项目当ASP 第一次发布时，Web 编程还比较困难，因为需要 IIS 来处理 ASP 页。后来，ASP.NET 2.0 和 Visual Studio 2005 通过引入网站开发模型使一切工作都变得容易了。借助该网站模型，您不必在 Visual Studio 中创建新项目，而是可以指向一个目录并开始编写网页和代码。此外，您还可以使用内置的 ASP.NET Development Server 快速测试站点，ASP.NET Development Server 将 ASP.NET 寄宿在一个本地进程中，并消除了必须安装 IIS 才能进行开发这一先决条件。该网站模型的魅力在于您在开发 Web 应用程序时无需考虑打包和部署。需要其他类时怎么办？向 App_Code 目录添加一个 .cs 文件即可开始编写。希望将可本地化的字符串存储在资源文件中时怎么办？向 App_GlobalResources 目录添加一个 .resx 文件并键入字符串。一切都顺顺当当；您根本就不必考虑编译和部署方面的事情。 在准备进行部署时，您有多种可选方案。最简单的方案是将文件复制到主运行服务器并按要求编译每一个文件（和在测试环境中一样）。第二种方案是使用 aspnet_compiler.exe 实用工具将应用程序预编译为二进制版本，之后将只剩下要放到服务器上的一组程序集、静态内容和配置文件。第三种方案也使用 aspnet_compiler.exe，但要创建一个可更新的二进制部署，其中 .as*x 文件保持不变（并且可修改），而所有代码文件都编译为二进制程序集。这似乎涵盖了每一种可能的情况，开发人员可以一心一意地编写 Web 应用程序，而在以后实际部署时再作打包和部署决定。不过，此模型也遭到了相当大的反对，特别是那些习惯了自己开发的 Web 项目是在实际项目文件中指定的实际项目的开发人员的反对，这些项目允许注入生成前和生成后函数、从生成过程排除文件以及使用命令行开关在调试和发布版本之间进行切换等操作。有鉴于此，Microsoft 迅速推出了 Web 应用程序项目（即 WAP），最初它是作为 Visual Studio 2005 的插件发布的，现在包含在 Visual Studio 2005 Service Pack 1 (SP1) 中，Visual Studio 2005 Service Pack 1 (SP1) 可从 /vstudio/support/vs2005sp1 下载。WAP 可替代与 Visual Studio .NET 2005 Web 项目模型非常接近的网站模型。新的 WAP 模型会在生成过程中编译所有源代码文件，并在本地的 /bin 目录中生成一个用于部署的程序集。WAP 还使得增量采用 ASP.NET 2.0 引入的新的分部类代码隐藏模型变得更加容易，因为现在您可以打开 Visual Studio .NET 2003 项目，并且在转换过程中只修改 .sln 和 .csproj（或 .vbproj）文件。然后可将每个文件及其代码隐藏类转换为与项目中任何其他文件都无关的新的分部类模型（操作方法是：在解决方案资源管理器中右键单击各个文件并选择“转换为 Web 应用程序”），也可以让它们仍然使用旧模型。这与将 Visual Studio .NET 2003 Web 项目转换为网站模型大不相同，转换为网站模型会同时转换所有文件，并且不支持增量采用。最后，还有一个称为“Web 部署项目”（本专栏的主题）的新项目类型，它引入了许多既针对网站项目又针对 Web 应用程序项目的附加部署选项。 Web 部署项目弥补了既针对网站应用程序又针对 Web 应用程序项目的部署选项中的遗留漏洞，并且可以简单而又可扩展地实现几乎任何部署方案。 为确切了解这一新项目类型增加了哪些内容，我们先来回顾一下在 Web 部署项目推出之前的情况。使用网站模型生成应用程序时，您可以选择对部署站点进行预编译。通过 Visual Studio 2005 中的“生成”|“发布”菜单或直接通过命令行实用工具 aspnet_compiler.exe，您可以访问预编译实用工具。显示了 Visual Studio 所显示的此工具的界面。使用发布实用工具时必须作出的第一个决定是 .as*x 文件在部署后是否可更新（在 aspnet_compiler.exe 命令行实用工具中使用 -u 开关的“允许更新此预编译站点”选项）。 此决定取决于在部署后是否希望能够在不重复整个部署过程的情况下对网页进行较少更改。事实上，您可能希望明确禁止对已部署网页进行任何修改，并要求所有修改都要遵循标准的部署（也希望遵循标准的测试）过程，在这种情况下，应选择将站点发布为不可更新。将站点发布为不可更新时，您可以完全删除所有 .as*x 文件，而只发布二进制程序集（以及配置文件和静态内容）。不过，如果没有物理文件，ASP.NET 将无法确定哪些类要用于哪些端点请求。例如，如果您的应用程序收到一个请求 Page1.aspx 的请求，而您已经使用了不可更新的二进制部署，则磁盘上很可能没有任何 Page1.aspx 文件，并且现有配置文件中没有任何内容来指示部署到 /bin 目录的程序集集合中哪个类应是该请求的实际处理程序。为弥补这一缺陷，编译过程还将生成一个 .compiled 文件集合，这些文件以简单的 XML 格式包含端点-类型映射和文件依赖关系信息，同时这些文件必须与所部署站点的 /bin 目录中的二进制程序集一起发布。例如，如果应用程序中原来有一个名为 Page1.aspx 的页，则 aspnet_compiler.exe 实用工具会生成一个名为 piled（哈希代码不定）的文件，其中包含以下 XML： 使用此实用工具发布网站时必须作出的另一个重要决定是确定生成的程序集的打包粒度。通过选中“使用固定命名和单页程序集”（或在 aspnet_compiler.exe 命令行实用工具中使用 -fixednames），既可为站点中的每个目录创建单独的程序集，又可为站点中的每个可编译文件创建单独的程序集。作出该决定并不像您可能想像的那么容易，因为每个选项都有其潜在问题。如果决定不使用 -fixednames 选项，则每次发布应用程序时都会生成一组全新的程序集，并且它们的名称与之前发布的程序集不同。这意味着部署更加复杂，因为在部署新的程序集之前必须删除主运行服务器上所有以前发布的程序集，否则在处理下一个请求时将生成冗余的类定义错误。使用 -fixednames 选项可以解决此问题，因为每个文件都将与命名清晰的程序集对应，而这些程序集在一次编译和下次编译中不会发生变化。不过，如果站点规模较大，则为每个网页、控件和母版页分别生成单独的程序集，很明显意味着您要管理成百上千个程序集的发布。Web 部署项目非常圆满地解决了部署中程序集粒度这一问题，如下所示。您还可以将程序集签名引入编译过程，以便创建具有强名称的不同版本的程序集，如果需要这也适用于全局程序集缓存 (GAC) 中的部署。通过使用 -aptca 选项，您可以使用程序集级别的属性 AllowPartiallyTrustedCallers 来标记生成的程序集，在将任何程序集部署到 GAC 并且以低等或中等信任级别运行 ASP.NET 的情况下，这是必要的。（请注意，此属性应仅应用于已证明不会暴露任何安全漏洞的程序集，因为如有漏洞，使用此属性可能招致引诱攻击。）有关发布站点的另一个细节是如果决定使用 Web 应用程序项目而不使用网站模型，则“生成”|“发布”对话框的外观将大不相同。Web 应用程序项目假定您希望将应用程序发布为可更新的 .as*x 文件和预编译的源文件（开发中它所使用的同一模型），因此仅针对二进制的部署选项不可用。此实用工具实质上更接近于“复制网站”实用工具（随网站一起提供）而不是“发布网站”实用工具，因为它需要复制由标准生成过程生成的文件。从技术上讲，即使您使用 Web 应用程序项目，也不会限制您使用仅针对二进制（不可更新）的部署。其实，WAP 生成的输出是一个有效的网站，然后您可以传递 aspnet_compiler.exe 实用工具来生成创建二进制部署。幸运的是，您只是不能从 Web 部署项目调整过的 Visual Studio 2005 界面调用它而已。Web 部署项目那么迄今为止所有现有的编译和部署选项中缺少什么呢？主要缺少两种功能：控制程序集命名（特别是为了进行部署）的功能，以及将所有输出的程序集合并为一个程序集从而简化部署的功能。Web 部署项目可以解决这两个问题。但或许更重要的是，它们还与网站应用程序和 Web 应用程序项目的部署问题中的许多遗留问题有关。它们的核心是，Web 部署项目（可从 /aa336619.aspx 下载）代表的只是向您解决方案中添加的另一个项目类型。与所有 Visual Studio 项目文件一样，Web 部署项目也是可在 IDE 中直接编译或从命令行运行的 MSBuild 脚本。不过，Web 部署项目包含用于编译和打包网站（或 Web 应用程序项目）的生成命令，而不指定要编译的源代码文件集合。这意味着它们会调用 aspnet_compiler.exe 实用工具（以及其他实用工具）来创建特定 Web 应用程序的部署。Web 部署项目是作为 Visual Studio 插件包提供的，其中包含了一个用于注入新项目的易用菜单项和一个用于控制所有可用设置的完整属性页集。若要向现有应用程序中添加新项目，可右键单击现有网站（或 Web 应用程序项目），然后选择“添加 Web 部署项目”项。此操作将把一个包含 MSBuild 脚本的新 .wdproj 文件添加到您的解决方案中，并会生成您所创建的应用程序的部署。将 Web 部署项目添加到您的解决方案之后，您就可以通过访问项目文件的属性页来精确控制项目的用途。新部署项目的默认设置是以可更新模式部署应用程序，所有 .as*x 文件都将保持不变，源文件则编译为部署在顶级 /bin 目录中的一个程序集。不管源应用程序使用网站模型还是使用 Web 应用程序项目模型，这些部署项目的作用都是相同的，这意味着无论您现在选择哪个开发模型都不会影响您的部署选项。Web 部署项目最重要的功能之一是它能够将所有部署都配置为二进制（不可更新）- 一个程序集，您可以为该程序集选择名称。使用此部署模型意味着，您只需将一个程序集放到活动站点的 /bin 目录中即可更新整个站点，并且在部署或处理导致错误的已部分部署的站点之前无需删除现有程序集。为端点映射部署 .compiled 文件仍是必需的，但只有当您在站点中添加、删除或移动页时这些文件才会发生变化。Web 部署项目提供了部署灵活性，使您可以在作出打包和部署决定时无需考虑 Web 应用程序的实际生成过程。借助 aspnet_compiler.exe 实用工具，ASP.NET 2.0 的原始版本部分地实现了开发和部署之间的这种独立性，但由于执行部署时的各种约束从未完全实现。Web 部署项目则已完全实现了开发和部署的分离，有关应用程序如何生成的决定将不再影响部署选择。合并程序集 Web 部署项目的功能主要是对通过 MSBuild 任务和新界面提供的现有实用工具进行重新打包，但除此之外还提供了几个全新功能。其中最引人关注的功能是程序集合并功能。安装 Web 部署项目时，您会发现安装目录（默认情况下是 %PROGRAMFILES%MSBuildMicrosoftWebDeploymentv8.0）中有一个名为 aspnet_merge.exe 的可执行文件。该可执行文件能够提取预编译站点的多个程序集输出并将这些程序集合并为一个程序集。如果选中 Web 部署项目中的合并选项，则该实用工具即可集成到生成脚本中。为了说明该实用工具的功能，我们来看一个没有可更新开关的预编译网站的输出。该输出的源应用程序包含两个子目录、一个顶级 global.asax 文件、一个在 App_Code 中定义的类以及一个用户控件。最终的编译结果是五个不同的程序集和一个 .compiled 文件集合。如果在此目录上运行 aspnet_merge.exe 实用工具（使用 -o 开关）来请求一个程序集输出，结果将是一个可管理性大大提高的单一程序集，其名称可以随意指定。虽然随 Web 部署项目一起提供的 aspnet_merge.exe 实用工具和相应的 MSBuild 任务是新的，但自从微软研究院将 Microsoft .NET Framework 1.1 包装成名为 ILMerge 的实用工具以来，用于合并程序集的基础技术实际上就已经诞生了。ILMerge 的最新版本可从 /mbarnett/ILMerge.aspx 下载。此实用工具现已直接集成到 aspnet_merge.exe 中，用于执行与合并程序集相关的所有繁重任务。其实，程序集合并是一项相当复杂的任务。您需要考虑签名、版本控制、其他程序集级别的属性、嵌入式资源和 XML 文档，同时还要管理冲突类型名称的详细信息等内容。ILMerge 实用工具可以为您管理所有这些内容，并用开关来控制有关该过程的各种决定。使用该实用工具还可以将 .exe 程序集转换为 .dll 程序集以便打包。例如，假定您有三个程序集：a.dll、b.dll 和 c.exe，并要将它们合并为一个库程序集。只要类型名称中没有冲突，下面的命令行就会生成一个新库 d.dll，其中包含在 a.dll、b.dll 和 c.exe 中定义的所有类型： ilmerge.exe /t:library /ndebug /out:d.dll a.dll b.dll c.exe可插入配置文件Web 部署项目提供的另一个全新功能是创建可插入配置文件。部署 Web 应用程序时，要确定一种方法来管理开发与部署之间配置文件的差别是一个常见问题。例如，您的一个本地测试数据库可能用于运行站点，另一个数据库用于暂存服务器，还有一个数据库用于主运行服务器。如果将连接字符串存储在 web.config 中（通常是在 connectionStrings 部分），那么在将应用程序推送到暂存服务器或实际工作环境时，就需要通过某种方式来修改这些字符串。Web 部署项目通过一个称为 ReplaceConfigSections 的新 MSBuild 任务提供了一个针对此问题的完全解决方案。通过此任务，您可以指定根据解决方案配置独立存储特定配置部分内容的独立文件。例如，您可以创建一个 debugconnectionstrings.config 文件来存储如下所示的 connectionStrings 配置部分的调试版本： 与此类似，接下来您可以为所定义的每个解决方案配置（发布、暂存等）创建单独的文件，并用它们各自部署环境所需的连接字符串进行填充。对于发布配置，可将文件命名为 releaseconnectionstrings.config，并按如下方式填充： 接下来，您可以对由 Web 部署项目添加的 MSBuild 脚本进行配置，以说明应替换主 web.config 文件中的哪些配置部分以及将提供替换内容的源文件。您可以手动修改脚本，但 Visual Studio 中生成脚本的属性页提供的漂亮界面可以为您代劳。在此例中，您是在设置调试解决方案配置的属性，因此选中“启用 Web.config 文件部分替换”选项并指定要随该文件一起替换为相应内容的部分： connectionStrings=debugconnectionstrings.config您可使用同一对话框页以相应的文件来设置发布解决方案配置（以及我们已定义的任何其他配置）的配置替换。在随后运行生成脚本时，ReplaceConfigSections 任务会从任何关联的配置文件中提取内容，并替换相应配置部分的内容，同时创建一个放到部署目录的新 web.config 文件。这种配置文件替换功能意味着您可以借助由源代码管理进行版本控制的文本文件，以一种易于管理的方式来维护部署环境之间的配置差异，并且不必使用提醒您在部署时更改连接字符串的粘滞便笺。应予以强调的是，此功能适用于配置文件的任何部分，包括自定义部分，因此如果其他配置部分（例如，appSettings）有差异，您也可以使用此生成任务轻松指定这些差异。创建可重用用户控件Web 部署项目有一个有趣的附带应用程序，该应用程序解决了一个已困扰 ASP.NET 开发人员多年的问题，即如何创建可重用用户控件以便进行跨应用程序共享。用户控件实质上就是复合的自定义控件，其子控件位于 .ascx 文件中。能够将设计器用于布局控件和添加处理程序对于大多数开发人员来说都是一个巨大帮助，因为在感觉上这和生成网页几乎完全相同，不同的是得到的 .ascx 文件可作为控件包含在任何网页中。而一直存在的不足是需要在应用程序的目录中保留实际的 .ascx 文件才能真正使用它。尽管已有用于实现跨应用程序共享 .ascx 控件的技术，但这些技术通常都涉及许多繁琐事务（如在应用程序之间创建共享虚拟目录或在请求时搜集由 ASP.NET 生成的临时程序集），并且从未让人感到满意。版本 2.0 中引入的 aspnet_compiler.exe 实用工具提供了一个比较好的解决方案。借助此编译器，您可以创建一个仅由用户控件组成的网站，并以不可更新模式发布该站点，以便生成可重用程序集。获得生成的程序集后，您可以将其部署到任何 Web 应用程序并像引用自定义控件那样引用该用户控件（而不是像针对 .ascx 文件那样使用 src 属性）。此技术的唯一缺点是，您要么必须接受由编译过程生成的随机命名程序集，要么必须选中编译器中的 fixednames 选项，以便为站点中的每个母版页各生成名称固定的程序集（而不是为整个集合只生成一个程序集）。Web 部署项目提供了用于创建真正可重用的用户控件程序集的决定性步骤。您可以使用只包含用户控件的网站，并通过添加 Web 部署项目来创建具有所选名称的单一输出程序集。创建一个要部署到 GAC 的签名程序集会更简单直接，这样无需在每个 /bin 目录中重新部署该程序集即可实现跨多个应用程序的控件共享。Web 部署项目的推出令人非常满意地完善了用于部署 ASP.NET 应用程序的工具集。现在可以用从所有源到所有二进制的任何方式部署应用程序，并且可以完全控制二进制程序集的生成、打包和命名。此外，Web 部署项目还提供了一个解决方案以便根据目标版本替换配置文件的各部分，并解决了可重用用户控件的分发问题。正在构建和部署 ASP.NET 应用程序的任何人肯定都会发现 Web 部署项目的某些方面非常有用，足以吸引他们立即开始使用 Web 部署项目1.2使用 AJAX Extensions 客户端进行 Web 服务调用从根本上讲，ASP.NET 自始至终都是一项服务器端技术。当然，在某些情况下 ASP.NET 会生成客户端 JavaScript，特别是在验证控件中以及在新推出的 Web 部件基础结构中，但它通常只是简单地将客户端属性转换成客户端行为。作为开发人员，在收到下一个 POST 请求之前不必考虑与客户端进行交互。对于需要使用客户端 JavaScript 和 DHTML 构建更具交互性的页面的开发人员而言，则需要在 ASP.NET 2.0 脚本回调功能提供的一些帮助下自己编写代码。这一情况在去年得到了彻底改变。在 2005 年 9 月的 Microsoft 在 Microsoft 专业开发人员大会上发布了一个新的 ASP.NET 插件（代号为“Atlas”），主要是为了充分利用客户端 JavaScript、DHTML 和 XMLHttpRequest 对象。其目的是帮助开发人员创建更具交互性的支持 AJAX 的 Web 应用程序。此框架从此更名为正式名称 Microsoft AJAX Library 和 ASP.NET 2.0 AJAX Extensions，它提供了许多出色的功能，包括客户端数据绑定、DHTML 动画和行为以及使用 UpdatePanel 实现的完善的对客户端 POST 回调的拦截。这些功能中的许多功能依赖的是以易于通过客户端 JavaScript 调用进行分析和交互的形式从服务器异步检索数据的能力。本月专栏的主题便是这一新的非常有用的能力，即在支持 ASP.NET 2.0 AJAX Extensions 的页面中通过客户端 JavaScript 调用服务器端 Web 服务的能力。使用 AJAX 调用 Web 服务 如果您曾经使用过 Microsoft .NET Framework 中的 Web 服务，无论是使用 wsel.exe 实用程序创建代理还是使用 Visual Studio 的“添加 Web 引用”功能，您就会习惯于使用 .NET 类型调用 Web 服务。实际上，通过 .NET 代理调用 Web 服务方法与在其他类上调用方法非常相似。代理会根据您传递的参数准备 XML，它会妥善地将它收到的 XML 响应转换成代理方法指定的 .NET 类型。开发人员可以非常方便地利用 .NET Framework 使用 Web 服务端点，这也使目前面向服务的应用程序变得可行。ASP.NET 2.0 AJAX Extensions 使得在浏览器中运行的客户端 JavaScript 实现了无缝的、与 Web 服务完全相同的代理生成体验。您可以编写一个在您的服务器上承载的 .asmx 文件，并通过一个客户端 JavaScript 类调用该服务上方法。例如，图1 显示了一个简单的 .asmx 服务，该服务实现了模拟的股票报价检索（使用随机数据）。除了标准的 .asmx Web 服务属性外，此服务还增添了 ScriptService 属性，使其同样可适用于 JavaScript 客户端。如果此 .asmx 文件部署在支持 ASP.NET AJAX 的 Web 应用程序中，您可以通过为您的 .aspx 文件中的 ScriptManager 控件添加 ServiceReference，从 JavaScript 调用服务的方法（当您使用支持 ASP.NET AJAX 的网站模板在 Visual Studio 中创建网站时，此控件会自动添加到您的 default.aspx 页面中）： 现在您可以通过任何客户端 JavaScript 例程，使用 MsdnMagazine.StockQuoteService 类调用服务的任何方法。由于调用的基本机制在本质上是异步的，因此没有同步方法可用。每个代理方法带有一个额外的参数（除了标准的输入参数外），该参数引用了另一个在该方法完成时异步调用的客户端 JavaScript 函数。显示的示例页面使用客户端 JavaScript 将调用股票报价 Web 服务的结果显示在页面上的标签 (span) 中。如果客户端 Web 服务调用出现了问题，您一定希望让客户端知道这一情况，通常明智的做法是在出现错误、中止或超时时，调用另一个方法进行传递。例如，您可以按如下所示更改上面显示的 OnLookup 方法，并额外添加一个 OnError 方法，以显示所有问题： function OnLookup() var stb = document.getElementById(_symbolTextBox); MsdnMagazine.StockQuoteService.GetStockQuote( stb.value, OnLookupComplete, OnError); function OnError(result) alert(Error: + result.get_message();这样，如果 Web 服务调用失败，您将通过警报框通知客户端。您还可以在从客户端发出的对任何 Web 服务的调用中加入 userContext 参数，该参数是作为 Web 方法的最后参数传入的任意字符串，它将作为额外的参数传播给成功和失败的方法。在这种情况下，将被请求股票的实际符号作为 userContext 进行传递会比较有意义，这样您就可在 OnLookupComplete 方法中显示它： function OnLookup() var stb = document.getElementById(_symbolTextBox); MsdnMagazine.StockQuoteService.GetStockQuote( stb.value, OnLookupComplete, OnError, stb.value);function OnLookupComplete(result, userContext) / userContext contains symbol passed into method var res = document.getElementById(_resultLabel); res.innerHTML = userContext + : + result + ;如果您发现您要对某个 Web 服务进行多个不同的调用，并且对于每个调用您重复使用相同的错误和/或完成方法，那么您还可以设置全局默认的失败和成功的回调方法。这就避免了在每次调用时都必须指定一对回调方法，而且您还可以为各个方法分别进行选择，使其忽略全局定义。以下是 OnLookup 方法的示例，其中设置了全局的（而不是对单个调用的）默认的成功和失败的回调方法。 / Set default callbacks for stock quote serviceMsdnMagazine.StockQuoteService.set_defaultSucceededCallback( OnLookupComplete);MsdnMagazine.StockQuoteService.set_defaultFailedCallback( OnError);function OnLookup() MsdnMagazine.StockQuoteService.GetStockQuote(stb.value);还有一种可以为您的 Web 服务方法构建完整的 .asmx 文件的有趣方法，就是将 Web 服务方法直接内嵌在页类中。如果为您希望调用的方法构建完整的 Web 服务端点没有意义，那么您可以在您的页面中公开一个可通过客户端 JavaScript 调用的 Web 方法，做法是向页面中添加一个服务器端方法（直接在页面中添加或者以代码隐藏的方式添加）并用 WebMethod 属性对其进行批注。然后您就可以通过客户端对象 PageMethods 调用它了。示例显示的是经过重新编写的股票报价服务示例，它完全包含在一个页中，而不是分割到各个 Web 服务中。请记住，这些客户端代理只能由 ASP.NET .asmx 端点、Windows Communication Foundation .svc 端点或直接内嵌在页面中的 WebMethod 生成，而且不是调用任意 Web 服务的通用机制。实际上，对于基本的 XmlHTTPRequest 对象有一般性限制，请求的范围仅限于加载页面的域（出于安全的原因），因此这一做法无法用于调用任意 Web 服务，无论客户端代理是否支持此操作。如果您发现需要调用外部 Web 服务，最好在您调用外部 Web 服务的 .NET 代理类（使用 wsdl.exe 或 Visual Studio 中的“添加 Web 引用”生成）的应用程序中设置一个桥接的 .asmx 端点。工作原理您可以采用标准的 .asmx Web 服务，几乎不做任何更改即可在浏览器中通过客户端 JavaScript 对其进行访问，乍看起来有些匪夷所思。秘密就在于注册了一个新的 .asmx HTTP 处理程序，并将其添加到了每个支持 ASP.NET AJAX 的网站的配置文件中： 如果对一个 .asmx 端点进行标准的 Web 服务请求，则这个新注册的处理程序将调用标准 Web 服务处理程序 (System.Web.Services.Protocols.WebServiceHandlerFactory)。但是，如果请求在 URL 中有后缀 /js 或者包含带有 mn= 变量的查询字符串（如 ?mn=GetStockQuote），则处理程序会返回一个 JavaScript 块，为 Web 服务创建一个客户端代理（带有 /js 的情况），或者会调用 WebService 派生类中定义的相应方法，并把响应打包在 JavaScript Object Notation (JSON) 编码的字符串中（带有 ?mn= 的情况）。 当页面包含对 .asmx 服务的客户端引用（通过 ScriptManager 控件中的 ServiceReference 元素）时，它会注入使用后缀 /js 引用 .asmx 文件的脚本元素，从而在客户端创建代理。例如，我在上面构建的股票报价页面会在其中显示以下脚本元素： 当然，这是在添加了对 Microsoft AJAX Library 的脚本引用的基础上，AJAX Library 中包含了与此代理进行交互所需的客户端功能。如果您尝试自己导航至此端点，您将看到以下 JavaScript（部分）： Type.registerNamespace(MsdnMagazine);MsdnMagazine.StockQuoteService=function() this._timeout = 0; this._userContext = null; this._succeeded = null; this._failed = null;MsdnMagazine.StockQuoteStotype=GetStockQuote:Sys.Net._WebMethod._createProxyMethod(this, GetStockQuote, MsdnMagazine.StockQuoteService.GetStockQuote, symbol), .此 JavaScript 使用每个包含 ScriptManager 控件的页面中所包含的 Microsoft AJAX Library 的功能（如命名空间和 WebMethod 类）。此 JavaScript 创建的代理方法经过初始化，利用此例中的查询字符串 ?mn=GetStockQuote 调用 .asmx 端点，因此无论您何时从客户端调用 MsdnMagazine.StockQuoteService.GetStockQuote，它都会变成对同一 .asmx 端点的异步 Web 请求。将客户端代理生成和服务器端对 JavaScript 发出的 Web 服务调用的支持相结合，意味着您可以以一种直观的方式包含对您的 .asmx Web 服务的客户端调用。序列化 基于 AJAX 的 Web 服务的默认序列化是 JSON。如果您注意到上一部分所显示的一系列页面操作，会发现 Web 服务请求和响应的主体部分类似于： Request: symbol:ABCResponse: 51这当然不是您在调用 .asmx Web 服务时所习惯看到的标准 XML 格式，因为 .asmx 端点在构建时已序列化到 XML 中，所以 ASP.NET 2.0 AJAX Extensions 所增加一个主要内容便是 JSON 序列化程序。实际上共有两个序列化程序：一个在 JavaScript 中实现，用于客户端，一个在 .NET 中实现，用于服务器，尤其用在 AJAX 客户端调用 .asmx 端点时。服务器端序列化程序可通过 Microsoft.Web.Script.Serialization.JavaScriptSerializer 使用，客户端序列化程序可通过 Sys.Serialization.JavaScriptSerializer 使用。使用 JSON 作为基于 XML 的序列化格式的一个主要优势是您只需简单地求得 JSON 字符串的值即可对 JavaScript 中的对象反序列化。客户端序列化程序类的反序列化方法最终会变得非常简短（去掉了错误检查）： Sys.Serialization.JavaScriptSerializer.deserialize= function()eval(+data+);而另一方面，JavaScriptSerializer 的序列化方法却更复杂了。使用 JSON 的另一优势就是它与对应的 XML 相比，其表示形式更加精简。与标准 Web 服务使用 XmlSerializer 将类型序列化到 XML 中非常类似，您可以采用几乎任何 .NET 类型并使用 JavaScriptSerializer 将其序列化到 JSON 中。如果您希望亲自尝试，只需调用 JavaScriptSerializer 类的 Serialize 方法。显示了一个示例控制台应用程序，此例中，它对复杂的 Person 类型进行序列化。（该程序必须包含对 Microsoft.Web.Extensions.dll 的程序集引用，该 DLL 随 ASP.NET AJAX Extensions 安装在全局程序集缓存 (GAC) 中。）控制台应用程序的输出将是 JSON 格式的 Person 类，或： Married:true,Age:33,FirstName:Bob,LastName:Smith正像 XmlSerializer 那样，JavaScriptSerializer 将仅对一种类型的公共可访问数据进行序列化，并且不支持对循环引用的解析。但任何可由标准 .asmx Web 服务序列化的类型也都能与此序列化程序一起正常工作（当然其中包括 DataSet）。鉴于这一点，您可以构建更复杂的 Web 服务，因为它处理复杂类型就像 .asmx 文件中定义的任何基于 SOAP 的 Web 服务一样轻松。示例显示了一个名为 MarriageService 的 Web 服务，它实现了 Marry 方法，它采用两个 Person 对象（正如前面定义的）并对其属性进行相应的修改。（本期的代码下载部分包含有此例附带的 ASP.NET 页面。）如果您选择在您的客户端脚本中使用 XML，该选项仍然可用。除了在定义 Web 服务时使用的标准 WebMethod 属性外，Microsoft.Web.Script.Services 命名空间中还有一个名为 ScriptMethod 的新属性，它具有 ResponseFormat 特性，该特性可设置为 Json 或 Xml（默认值为 Json）。 namespace PS ScriptService WebService(Namespace = /ws) WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1) public class StockQuoteService : WebService WebMethod public int GetStockQuote(string symbol) return (new Random().Next(0, 120); 这样，序列化的响应将为： 74当您通过客户端 JavaScript 调用此方法来处理 XML 响应时，怎样选择由您自己决定。如果您计划对其执行转换，或者已经在使用 MSXML，那么这会非常有用。总结有必要指出的是，ASP.NET 2.0 AJAX Extensions 提供了两个预先构建的服务，用于通过客户端代码访问特定 ASP.NET 2.0 应用程序服务，它们是：ProfileService 和 AuthenicationService。使用这两个客户端代理类，您可以为单个客户端设置和检索配置文件值，并完全在客户端脚本中执行身份验证（通过默认的成员资格提供程序）和授予身份验证 cookies。尽管许多有关 ASP.NET 2.0 AJAX Extensions 的讨论和演示都偏重于介绍那些使用户界面具备更高响应能力的漂亮控件，但是能够直接通过客户端 JavaScript 调用 Web 服务是最吸引人、最实用的功能之一。凭借完善的 .NET Framework/JSON 序列化程序、与熟悉的 .asmx Web 服务的直接集成、对批处理的支持和自动生成的与外部 Web 服务的桥接，如此全面且深入地支持 Web 服务可能会使这一功能成为所有功能中最吸引人的功能。附件2：外文原文Extreme ASP.NET1.1Web Deployment ProjectsWhen ASP was first released, Web programming was more difficult because you needed IIS to serve your ASP pages. Later, ASP.NET 2.0 and Visual Studio 2005 made everything easier by introducing the Web site model of development. Instead of creating a new project inside Visual Studio, the Web site model lets you point to a directory and start writing pages and code. Furthermore, you can quickly test your site with the built-in ASP.NET Development Server, which hosts ASP.NET in a local process and obviates the need to install IIS to begin developing. The beauty of the Web site model is that you