资源描述：
《毕业设计外文翻译》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。
毕业设计外文翻译个人总结，仅供交流南京邮电大学毕业设计(论文)外文资料翻译学院专 业学生姓名班级学号外文出处附件：1.外文资料翻译译文；2.外文原文指导教师评价：1．翻译内容与课题的结合度：□优□良□中□差2．翻译内容的准确、流畅：□优□良□中□差3．专业词汇翻译的准确性：□优□良□中□差4．翻译字符数是否符合规定要求：□符合□不符合 指导教师签名： 年 月 日附件1：外文资料翻译译文非常ASP.NET1.1Web部署项目 当ASP第一次发布时，Web编程还比较困难，因为需要IIS来处理ASP页。后来，ASP.NET2.0和VisualStudio(r)2005通过引入网站开发模型使一切工作都变得容易了。借助该网站模型，您不必在VisualStudio中创建新项目，而是可以指向一个目录并开始编写网页和代码。此外，您还可以使用内置的ASP.NETDevelopmentServer快速测试站点，ASP.NETDevelopmentServer将ASP.NET寄宿在一个本地进程中，并消除了必须安装IIS才能进行开发这一先决条件。该网站模型的魅力在于您在开发Web应用程序时无需考虑打包和部署。需要其他类时怎么办？向App_Code目录添加一个.cs文件即可开始编写。希望将可本地化的字符串存储在资源文件中时怎么办？向App_GlobalResources目录添加一个.resx文件并键入字符串。一切都顺顺当当；您根本就不必考虑编译和部署方面的事情。 在准备进行部署时，您有多种可选方案。最简单的方案是将文件复制到主运行服务器并按要求编译每一个文件（和在测试环境中一样）。第二种方案是使用aspnet_compiler.exe实用工具将应用程序预编译为二进制版本，之后将只剩下要放到服务器上的一组程序集、静态内容和配置文件。第三种方案也使用aspnet_compiler.exe，但要创建一个可更新的二进制部署，其中.as*x文件保持不变（并且可修改），而所有代码文件都编译为二进制程序集。 这似乎涵盖了每一种可能的情况，开发人员可以一心一意地编写Web应用程序，而在以后实际部署时再作打包和部署决定。不过，此模型也遭到了相当大的反对，特别是那些习惯了自己开发的Web 项目是在实际项目文件中指定的实际项目的开发人员的反对，这些项目允许注入生成前和生成后函数、从生成过程排除文件以及使用命令行开关在调试和发布版本之间进行切换等操作。有鉴于此，Microsoft迅速推出了Web应用程序项目（即WAP），最初它是作为VisualStudio2005的插件发布的，现在包含在VisualStudio2005ServicePack1(SP1)中，VisualStudio2005ServicePack1(SP1)可从msdn.microsoft.com/vstudio/support/vs2005sp1下载。 WAP可替代与VisualStudio.NET2005Web项目模型非常接近的网站模型。新的WAP模型会在生成过程中编译所有源代码文件，并在本地的/bin目录中生成一个用于部署的程序集。WAP还使得增量采用ASP.NET2.0引入的新的分部类代码隐藏模型变得更加容易，因为现在您可以打开VisualStudio.NET2003项目，并且在转换过程中只修改.sln和.csproj（或.vbproj）文件。然后可将每个文件及其代码隐藏类转换为与项目中任何其他文件都无关的新的分部类模型（操作方法是：在解决方案资源管理器中右键单击各个文件并选择"转换为Web应用程序"），也可以让它们仍然使用旧模型。这与将VisualStudio.NET2003Web项目转换为网站模型大不相同，转换为网站模型会同时转换所有文件，并且不支持增量采用。 最后，还有一个称为"Web部署项目"（本专栏的主题）的新项目类型，它引入了许多既针对网站项目又针对Web应用程序项目的附加部署选项。Web部署项目弥补了既针对网站应用程序又针对Web应用程序项目的部署选项中的遗留漏洞，并且可以简单而又可扩展地实现几乎任何部署方案。为确切了解这一新项目类型增加了哪些内容，我们先来回顾一下在Web部署项目推出之前的情况。 使用网站模型生成应用程序时，您可以选择对部署站点进行预编译。通过VisualStudio2005中的"生成"|"发布"菜单或直接通过命令行实用工具aspnet_compiler.exe，您可以访问预编译实用工具。显示了VisualStudio所显示的此工具的界面。 使用发布实用工具时必须作出的第一个决定是.as*x文件在部署后是否可更新（在aspnet_compiler.exe命令行实用工具中使用-u开关的"允许更新此预编译站点"选项）。 此决定取决于在部署后是否希望能够在不重复整个部署过程的情况下对网页进行较少更改。事实上，您可能希望明确禁止对已部署网页进行任何修改，并要求所有修改都要遵循标准的部署（也希望遵循标准的测试）过程，在这种情况下，应选择将站点发布为不可更新。 将站点发布为不可更新时，您可以完全删除所有.as*x文件，而只发布二进制程序集（以及配置文件和静态内容）。不过，如果没有物理文件，ASP.NET将无法确定哪些类要用于哪些端点请求。例如，如果您的应用程序收到一个请求Page1.aspx的请求，而您已经使用了不可更新的二进制部署，则磁盘上很可能没有任何Page1.aspx文件，并且现有配置文件中没有任何内容来指示部署到/bin目录的程序集集合中哪个类应是该请求的实际处理程序。为弥补这一缺陷，编译过程还将生成一个.compiled文件集合，这些文件以简单的XML格式包含端点-类型映射和文件依赖关系信息，同时这些文件必须与所部署站点的/bin目录中的二进制程序集一起发布。例如，如果应用程序中原来有一个名为Page1.aspx的页，则aspnet_compiler.exe实用工具会生成一个名为page1.aspx.cdcab7d2.compiled（哈希代码不定）的文件，其中包含以下XML： 使用此实用工具发布网站时必须作出的另一个重要决定是确定生成的程序集的打包粒度。通过选中"使用固定命名和单页程序集"（或在aspnet_compiler.exe命令行实用工具中使用 -fixednames），既可为站点中的每个目录创建单独的程序集，又可为站点中的每个可编译文件创建单独的程序集。作出该决定并不像您可能想像的那么容易，因为每个选项都有其潜在问题。如果决定不使用-fixednames选项，则每次发布应用程序时都会生成一组全新的程序集，并且它们的名称与之前发布的程序集不同。这意味着部署更加复杂，因为在部署新的程序集之前必须删除主运行服务器上所有以前发布的程序集，否则在处理下一个请求时将生成冗余的类定义错误。使用-fixednames选项可以解决此问题，因为每个文件都将与命名清晰的程序集对应，而这些程序集在一次编译和下次编译中不会发生变化。不过，如果站点规模较大，则为每个网页、控件和母版页分别生成单独的程序集，很明显意味着您要管理成百上千个程序集的发布。Web部署项目非常圆满地解决了部署中程序集粒度这一问题，如下所示。 您还可以将程序集签名引入编译过程，以便创建具有强名称的不同版本的程序集，如果需要这也适用于全局程序集缓存(GAC)中的部署。通过使用-aptca选项，您可以使用程序集级别的属性AllowPartiallyTrustedCallers来标记生成的程序集，在将任何程序集部署到GAC并且以低等或中等信任级别运行ASP.NET的情况下，这是必要的。（请注意，此属性应仅应用于已证明不会暴露任何安全漏洞的程序集，因为如有漏洞，使用此属性可能招致引诱攻击。） 有关发布站点的另一个细节是如果决定使用Web应用程序项目而不使用网站模型，则"生成"|"发布"对话框的外观将大不相同。Web应用程序项目假定您希望将应用程序发布为可更新的.as*x文件和预编译的源文件（开发中它所使用的同一模型），因此仅针对二进制的部署选项不可用。此实用工具实质上更接近于"复制网站"实用工具（随网站一起提供）而不是"发布网站"实用工具，因为它需要复制由标准生成过程生成的文件。 从技术上讲，即使您使用Web应用程序项目，也不会限制您使用仅针对二进制（不可更新）的部署。其实，WAP生成的输出是一个有效的网站，然后您可以传递aspnet_compiler.exe实用工具来生成创建二进制部署。幸运的是，您只是不能从Web部署项目调整过的VisualStudio2005界面调用它而已。Web部署项目 那么迄今为止所有现有的编译和部署选项中缺少什么呢？主要缺少两种功能：控制程序集命名（特别是为了进行部署）的功能，以及将所有输出的程序集合并为一个程序集从而简化部署的功能。Web部署项目可以解决这两个问题。但或许更重要的是，它们还与网站应用程序和Web应用程序项目的部署问题中的许多遗留问题有关。 它们的核心是，Web部署项目（可从msdn2.microsoft.com/aa336619.aspx下载）代表的只是向您解决方案中添加的另一个项目类型。与所有VisualStudio项目文件一样，Web部署项目也是可在IDE中直接编译或从命令行运行的MSBuild脚本。不过，Web部署项目包含用于编译和打包网站（或Web应用程序项目）的生成命令，而不指定要编译的源代码文件集合。这意味着它们会调用aspnet_compiler.exe实用工具（以及其他实用工具）来创建特定Web应用程序的部署。Web部署项目是作为VisualStudio插件包提供的，其中包含了一个用于注入新项目的易用菜单项和一个用于控制所有可用设置的完整属性页集。若要向现有应用程序中添加新项目，可右键单击现有网站（或Web应用程序项目），然后选择"添加Web部署项目"项。此操作将把一个包含MSBuild脚本的新.wdproj文件添加到您的解决方案中，并会生成您所创建的应用程序的部署。 将Web部署项目添加到您的解决方案之后，您就可以通过访问项目文件的属性页来精确控制项目的用途。新部署项目的默认设置是以可更新模式部署应用程序，所有.as*x文件都将保持不变，源文件则编译为部署在顶级/bin目录中的一个程序集。不管源应用程序使用网站模型还是使用Web应用程序项目模型，这些部署项目的作用都是相同的，这意味着无论您现在选择哪个开发模型都不会影响您的部署选项。Web部署项目最重要的功能之一是它能够将所有部署都配置为二进制（不可更新）-一个程序集，您可以为该程序集选择名称。使用此部署模型意味着，您只需将一个程序集放到活动站点的/bin目录中即可更新整个站点，并且在部署或处理导致错误的已部分部署的站点之前无需删除现有程序集。为端点映射部署.compiled文件仍是必需的，但只有当您在站点中添加、删除或移动页时这些文件才会发生变化。 Web部署项目提供了部署灵活性，使您可以在作出打包和部署决定时无需考虑Web应用程序的实际生成过程。借助aspnet_compiler.exe实用工具，ASP.NET2.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(r).NETFramework1.1包装成名为ILMerge的实用工具以来，用于合并程序集的基础技术实际上就已经诞生了。ILMerge的最新版本可从research.microsoft.com/~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.dlla.dllb.dllc.exe可插入配置文件 Web部署项目提供的另一个全新功能是创建可插入配置文件。部署Web应用程序时，要确定一种方法来管理开发与部署之间配置文件的差别是一个常见问题。例如，您的一个本地测试数据库可能用于运行站点，另一个数据库用于暂存服务器，还有一个数据库用于主运行服务器。如果将连接字符串存储在web.config中（通常是在connectionStrings部分），那么在将应用程序推送到暂存服务器或实际工作环境时，就需要通过某种方式来修改这些字符串。Web部署项目通过一个称为ReplaceConfigSections的新MSBuild任务提供了一个针对此问题的完全解决方案。 通过此任务，您可以指定根据解决方案配置独立存储特定配置部分内容的独立文件。例如，您可以创建一个debugconnectionstrings.config文件来存储如下所示的connectionStrings配置部分的调试版本： 与此类似，接下来您可以为所定义的每个解决方案配置（发布、暂存等）创建单独的文件，并用它们各自部署环境所需的连接字符串进行填充。对于发布配置，可将文件命名为 releaseconnectionstrings.config，并按如下方式填充： 接下来，您可以对由Web部署项目添加的MSBuild脚本进行配置，以说明应替换主web.config文件中的哪些配置部分以及将提供替换内容的源文件。您可以手动修改脚本，但VisualStudio中生成脚本的属性页提供的漂亮界面可以为您代劳。在此例中，您是在设置调试解决方案配置的属性，因此选中"启用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使用AJAXExtensions客户端进行Web服务调用 从根本上讲，ASP.NET自始至终都是一项服务器端技术。当然，在某些情况下ASP.NET会生成客户端JavaScript，特别是在验证控件中以及在新推出的Web 部件基础结构中，但它通常只是简单地将客户端属性转换成客户端行为。作为开发人员，在收到下一个POST请求之前不必考虑与客户端进行交互。对于需要使用客户端JavaScript和DHTML构建更具交互性的页面的开发人员而言，则需要在ASP.NET2.0脚本回调功能提供的一些帮助下自己编写代码。这一情况在去年得到了彻底改变。 在2005年9月的Microsoft在Microsoft专业开发人员大会上发布了一个新的ASP.NET插件（代号为"Atlas"），主要是为了充分利用客户端JavaScript、DHTML和XMLHttpRequest对象。其目的是帮助开发人员创建更具交互性的支持AJAX的Web应用程序。此框架从此更名为正式名称Microsoft(r)AJAXLibrary和ASP.NET2.0AJAXExtensions，它提供了许多出色的功能，包括客户端数据绑定、DHTML动画和行为以及使用UpdatePanel实现的完善的对客户端POST回调的拦截。这些功能中的许多功能依赖的是以易于通过客户端JavaScript调用进行分析和交互的形式从服务器异步检索数据的能力。本月专栏的主题便是这一新的非常有用的能力，即在支持ASP.NET2.0AJAXExtensions的页面中通过客户端JavaScript调用服务器端Web服务的能力。使用AJAX调用Web服务如果您曾经使用过Microsoft.NETFramework中的Web服务，无论是使用wsel.exe实用程序创建代理还是使用VisualStudio(r)的"添加Web引用"功能，您就会习惯于使用.NET类型调用Web服务。实际上，通过.NET代理调用Web服务方法与在其他类上调用方法非常相似。代理会根据您传递的参数准备XML，它会妥善地将它收到的XML响应转换成代理方法指定的.NET类型。开发人员可以非常方便地利用.NETFramework使用Web服务端点，这也使目前面向服务的应用程序变得可行。 ASP.NET2.0AJAXExtensions使得在浏览器中运行的客户端JavaScript实现了无缝的、与Web服务完全相同的代理生成体验。您可以编写一个在您的服务器上承载的.asmx文件，并通过一个客户端JavaScript类调用该服务上方法。例如，图1显示了一个简单的.asmx服务，该服务实现了模拟的股票报价检索（使用随机数据）。 除了标准的.asmxWeb服务属性外，此服务还增添了ScriptService属性，使其同样可适用于JavaScript客户端。如果此.asmx文件部署在支持ASP.NETAJAX的Web应用程序中，您可以通过为您的.aspx文件中的ScriptManager控件添加ServiceReference，从JavaScript调用服务的方法（当您使用支持ASP.NETAJAX的网站模板在VisualStudio中创建网站时，此控件会自动添加到您的default.aspx页面中）： 现在您可以通过任何客户端JavaScript例程，使用MsdnMagazine.StockQuoteService类调用服务的任何方法。由于调用的基本机制在本质上是异步的，因此没有同步方法可用。每个代理方法带有一个额外的参数（除了标准的输入参数外），该参数引用了另一个在该方法完成时异步调用的客户端JavaScript函数。显示的示例页面使用客户端JavaScript将调用股票报价Web服务的结果显示在页面上的标签(span)中。 如果客户端Web服务调用出现了问题，您一定希望让客户端知道这一情况，通常明智的做法是在出现错误、中止或超时时，调用另一个方法进行传递。例如，您可以按如下所示更改上面显示的OnLookup方法，并额外添加一个OnError方法，以显示所有问题： functionOnLookup() { varstb=document.getElementById("_symbolTextBox"); MsdnMagazine.StockQuoteService.GetStockQuote( stb.value,OnLookupComplete,OnError); } functionOnError(result) {个人总结，仅供交流 alert("Error:"+result.get_message()); } 这样，如果Web服务调用失败，您将通过警报框通知客户端。您还可以在从客户端发出的对任何Web服务的调用中加入userContext参数，该参数是作为Web方法的最后参数传入的任意字符串，它将作为额外的参数传播给成功和失败的方法。在这种情况下，将被请求股票的实际符号作为userContext进行传递会比较有意义，这样您就可在OnLookupComplete方法中显示它： functionOnLookup() { varstb=document.getElementById("_symbolTextBox"); MsdnMagazine.StockQuoteService.GetStockQuote( stb.value,OnLookupComplete,OnError,stb.value); } functionOnLookupComplete(result,userContext) { //userContextcontainssymbolpassedintomethod varres=document.getElementById("_resultLabel"); res.innerHTML=userContext+":"+result+""; } 如果您发现您要对某个Web服务进行多个不同的调用，并且对于每个调用您重复使用相同的错误和/或完成方法，那么您还可以设置全局默认的失败和成功的回调方法。这就避免了在每次调用时都必须指定一对回调方法，而且您还可以为各个方法分别进行选择，使其忽略全局定义。以下是OnLookup方法的示例，其中设置了全局的（而不是对单个调用的）默认的成功和失败的回调方法。 //Setdefaultcallbacksforstockquoteservice MsdnMagazine.StockQuoteService.set_defaultSucceededCallback( OnLookupComplete); MsdnMagazine.StockQuoteService.set_defaultFailedCallback( OnError); functionOnLookup() { MsdnMagazine.StockQuoteService.GetStockQuote(stb.value); } 还有一种可以为您的Web服务方法构建完整的.asmx文件的有趣方法，就是将Web服务方法直接内嵌在页类中。如果为您希望调用的方法构建完整的Web服务端点没有意义，那么您可以在您的页面中公开一个可通过客户端JavaScript调用的Web方法，做法是向页面中添加一个服务器端方法（直接在页面中添加或者以代码隐藏的方式添加）并用WebMethod属性对其进行批注。然后您就可以通过客户端对象PageMethods调用它了。示例显示的是经过重新编写的股票报价服务示例，它完全包含在一个页中，而不是分割到各个Web服务中。 请记住，这些客户端代理只能由ASP.NET.asmx端点、WindowsCommunicationFoundation.svc端点或直接内嵌在页面中的WebMethod生成，而且不是调用任意Web服务的通用机制。实际上，对于基本的XmlHTTPRequest对象有一般性限制，请求的范围仅限于加载页面的域（出于安全的原因），因此这一做法无法用于调用任意Web服务，无论客户端代理是否支持此操作。如果您发现需要调用外部Web服务，最好在您调用外部Web服务的.NET代理类（使用wsdl.exe或VisualStudio中的"添加Web引用"生成）的应用程序中设置一个桥接的.asmx端点。工作原理 您可以采用标准的.asmxWeb服务，几乎不做任何更改即可在浏览器中通过客户端JavaScript对其进行访问，乍看起来有些匪夷所思。秘密就在于注册了一个新的.asmxHTTP处理程序，并将其添加到了每个支持ASP.NETAJAX的网站的配置文件中： 如果对一个.asmx端点进行标准的Web服务请求，则这个新注册的处理程序将调用标准Web服务处理程序(System.Web.Services.Protocols.WebServiceHandlerFactory)。但是，如果请求在URL中有后缀/js或者包含带有mn=变量的查询字符串（如?mn=GetStockQuote），则处理程序会返回一个JavaScript块，为Web服务创建一个客户端代理（带有/js的情况），或者会调用WebService派生类中定义的相应方法，并把响应打包在JavaScriptObjectNotation(JSON)编码的字符串中（带有?mn=的情况）。 当页面包含对.asmx服务的客户端引用（通过ScriptManager控件中的ServiceReference元素）时，它会注入使用后缀/js引用.asmx文件的脚本元素，从而在客户端创建代理。例如，我在上面构建的股票报价页面会在其中显示以下脚本元素： 当然，这是在添加了对MicrosoftAJAXLibrary的脚本引用的基础上，AJAXLibrary中包含了与此代理进行交互所需的客户端功能。如果您尝试自己导航至此端点，您将看到以下JavaScript（部分）： Type.registerNamespace('MsdnMagazine'); MsdnMagazine.StockQuoteService=function(){ this._timeout=0; this._userContext=null; this._succeeded=null; this._failed=null; } MsdnMagazine.StockQuoteService.prototype={ GetStockQuote:Sys.Net._WebMethod._createProxyMethod(this, "GetStockQuote", "MsdnMagazine.StockQuoteService.GetStockQuote", "symbol"),... } 此JavaScript使用每个包含ScriptManager控件的页面中所包含的MicrosoftAJAXLibrary的功能（如命名空间和WebMethod类）。此JavaScript创建的代理方法经过初始化，利用此例中的查询字符串?mn=GetStockQuote调用.asmx端点，因此无论您何时从客户端调用MsdnMagazine.StockQuoteService.GetStockQuote，它都会变成对同一.asmx端点的异步Web请求。将客户端代理生成和服务器端对JavaScript发出的Web服务调用的支持相结合，意味着您可以以一种直观的方式包含对您的.asmxWeb服务的客户端调用。序列化基于AJAX的Web服务的默认序列化是JSON。如果您注意到上一部分所显示的一系列页面操作，会发现Web服务请求和响应的主体部分类似于： Request:{"symbol":"ABC"} Response:51 这当然不是您在调用.asmxWeb服务时所习惯看到的标准XML格式，因为.asmx端点在构建时已序列化到XML中，所以ASP.NET2.0AJAXExtensions所增加一个主要内容便是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.NETAJAXExtensions安装在全局程序集缓存(GAC)中。） 控制台应用程序的输出将是JSON格式的Person类，或： {"Married":true,"Age":33,"FirstName":"Bob","LastName":"Smith"} 正像XmlSerializer那样，JavaScriptSerializer将仅对一种类型的公共可访问数据进行序列化，并且不支持对循环引用的解析。但任何可由标准.asmxWeb服务序列化的类型也都能与此序列化程序一起正常工作（当然其中包括DataSet）。鉴于这一点，您可以构建更复杂的Web服务，因为它处理复杂类型就像.asmx文件中定义的任何基于SOAP的Web服务一样轻松。 示例显示了一个名为MarriageService的Web服务，它实现了Marry方法，它采用两个Person对象（正如前面定义的）并对其属性进行相应的修改。（本期的代码下载部分包含有此例附带的 ASP.NET页面。） 如果您选择在您的客户端脚本中使用XML，该选项仍然可用。除了在定义Web服务时使用的标准WebMethod属性外，Microsoft.Web.Script.Services命名空间中还有一个名为ScriptMethod的新属性，它具有ResponseFormat特性，该特性可设置为Json或Xml（默认值为Json）。 namespacePS { [ScriptService] [WebService(Namespace="http://pluralsight.com/ws")] [WebServiceBinding(ConformsTo=WsiProfiles.BasicProfile1_1)] publicclassStockQuoteService:WebService { [WebMethod] publicintGetStockQuote(stringsymbol) { return(newRandom()).Next(0,120); } } } 这样，序列化的响应将为： 74 当您通过客户端JavaScript调用此方法来处理XML响应时，怎样选择由您自己决定。如果您计划对其执行转换，或者已经在使用MSXML，那么这会非常有用。总结 有必要指出的是，ASP.NET2.0AJAXExtensions提供了两个预先构建的服务，用于通过客户端代码访问特定ASP.NET2.0应用程序服务，它们是：ProfileService和 AuthenicationService。使用这两个客户端代理类，您可以为单个客户端设置和检索配置文件值，并完全在客户端脚本中执行身份验证（通过默认的成员资格提供程序）和授予身份验证cookies。 尽管许多有关ASP.NET2.0AJAXExtensions的讨论和演示都偏重于介绍那些使用户界面具备更高响应能力的漂亮控件，但是能够直接通过客户端JavaScript调用Web服务是最吸引人、最实用的功能之一。凭借完善的.NETFramework/JSON序列化程序、与熟悉的.asmxWeb服务的直接集成、对批处理的支持和自动生成的与外部Web服务的桥接，如此全面且深入地支持Web服务可能会使这一功能成为所有功能中最吸引人的功能。附件2：外文原文ExtremeASP.NET1.1WebDeploymentProjectsWhenASPwasfirstreleased,WebprogrammingwasmoredifficultbecauseyouneededIIStoserveyourASPpages.Later,ASP.NET2.0andVisualStudio(r)2005madeeverythingeasierbyintroducingtheWebsitemodelofdevelopment.InsteadofcreatinganewprojectinsideVisualStudio,theWebsitemodelletsyoupointtoadirectoryandstartwritingpagesandcode.Furthermore,youcanquicklytestyoursitewiththebuilt-inASP.NETDevelopmentServer,whichhostsASP.NETinalocalprocessandobviatestheneedtoinstallIIStobegindeveloping.ThebeautyoftheWebsitemodelisthatyoucandevelopyourWebapplicationwithoutthinkingaboutpackaginganddeployment.Needanotherclass?Adda.csfiletotheApp_Codedirectoryandstartwriting.Wanttostorelocalizablestringsinaresourcefile?Adda.resxfiletotheApp_GlobalResourcesdirectoryandtypeinthestrings.Everythingjustworks;you don'thavetothinkaboutthecompilationanddeploymentaspectatall.Whenyouarereadytodeploy,youhaveseveraloptions.Thesimplestchoiceistocopyyourfilestoaliveserverandleteverythingbecompiledon-demand(asitwasinyourtestenvironment).Thesecondoptionistousetheaspnet_compiler.exeutilityandprecompiletheapplicationintoabinaryrelease,whichleavesyounothingbutacollectionofassemblies,staticcontent,andconfigurationfilestopushtotheserver.Thethirdoptionistoagainuseaspnet_compiler.exe,buttocreateanupdateablebinarydeploymentwhereyour.as*xfilesremainintact(andmodifiable)andallofyourcodefilesarecompiledintobinaryassemblies.Thisseemstocovereverypossiblescenario,leavingthedevelopertofocussimplyonwritingtheWebapplication,withpackaginganddeploymentdecisionstobemadelaterwhentheapplicationisactuallydeployed.Therewasafairamountofbacklashagainstthismodel,however,especiallyfromdeveloperswhowereusedtotheirWebprojectsbeingrealprojects,specifiedinrealprojectfiles,thatletyouinjectpre-andpost-buildfunctions,excludefilesfromthebuildprocess,movebetweendebugandreleasebuildswithacommand-lineswitch,andsoon.Inresponse,MicrosoftquicklyintroducedtheWebApplicationProjectorWAP,initiallyreleasedasanadd-intoVisualStudio2005,andnowincludedinVisualStudio2005Serviceavailablefordownloadfrommsdn.microsoft.com/vstudio/support/vs2005sp1.WAPprovidesanalternativetotheWebsitemodelthatismuchclosertotheVisualStudio.NET2005WebProjectmodel.ThenewWAPmodelcompilesallofthesourcecodefilesduringthebuildprocessandgeneratesasingleassemblyinthelocal /bindirectoryfordeployment.WAPalsomakesitmucheasiertoincrementallyadoptthenewpartialclasscodebehindmodelintroducedinASP.NET2.0becauseyoucannowopenaVisualStudio.NET2003projectandonlyyour.slnand.csproj(or.vbproj)fileswillbemodifiedduringtheconversion.Youcanthenconverteachfileanditscodebehindclasstothenewpartialclassmodelindependentlyofanyotherfileintheproject(byright-clickingonthefileintheSolutionExplorerandselectingConverttoWebApplication),orjustleavethemusingtheoldmodel.ThisisincontrasttoconvertingaVisualStudio.NET2003WebprojecttotheWebsitemodel,whichconvertsallfilesatonceanddoesnotsupportincrementaladoption.Finally,thereisanewprojecttypecalledWebDeploymentProjects(themaintopicofthiscolumn),whichintroducesmyriadadditionaldeploymentoptionsforbothWebsiteprojectsandWebApplicationProjects.WebDeploymentProjectsfilltheremainingholesinthedeploymentoptionsforbothWebsiteappsandWebApplicationProjectsandmakeitpossibletoimplementpracticallyanydeploymentscenarioinasimpleandextensibleway.Tounderstandexactlywhatthisnewprojecttypeadds,let'sfirstreviewwhatwehadbeforeWebDeploymentProjectswereavailable.个人总结，仅供交流WhenyoubuildanapplicationusingtheWebsitemodel,youhavetheoptionofprecompilingthesitefordeployment.YoucanaccesstheprecompilationutilitythroughtheBuild|PublishmenuinVisualStudio2005ordirectlythroughthecommand-lineutilityaspnet_compiler.exe.Figure1showstheinterfacetothistoolexposedbyVisualStudio. Thefirstdecisionyouhavetomakewhenusingthepublishutilityiswhetheryouwantyour.as*xfilestobeupdatableoncedeployed(usethe"Allowthisprecompiledsitetobeupdatable"optionof-uswitchintheaspnet_compiler.execommand-lineutility).Thisdecisionhingesonwhetheryouwanttobeabletomakeminorchangestoyourpagesoncedeployedwithouthavingtogothroughtheentiredeploymentprocessagain.Youmay,infact,wanttoexplicitlydisallowanymodificationstothedeployedpagesandrequirethatallmodificationsgothroughthestandarddeployment(andhopefullytesting)process,inwhichcasepublishingthesiteasnotupdatableistheproperchoice.Whenasiteispublishedasnotupdatable,itispossibletocompletelyremoveall.as*xfilesandpublishonlybinaryassemblies(plusconfigurationfilesandstaticcontent).However,withoutthephysicalfilesinplace,itisimpossibleforASP.NETtotellwhichclassestouseforwhichendpointrequests.Forexample,ifarequestcomesintoyourapplicationforPage1.aspxandyouhaveusednon-updatablebinarydeployment,thereverywellmaynotbeanyPage1.aspxfileondisk,andthereisnothingintheexistingconfigurationfilestoindicatewhichclassinthecollectionofassembliesdeployedtothe/bindirectoryshouldactuallybethehandlerforthisrequest.Toremedythis,thecompilationprocesswillalsogenerateacollectionof.compiledfilesthatcontainendpoint-to-typemappingandfiledependencyinformationinasimpleXMLformat,andthesefilesmustbepublishedalongwiththebinaryassembliesinthe/bindirectoryofthedeployedsite.Asanexample,ifyoudidhaveapagenamedPage1.aspxinyourapplication,theaspnet_compiler.exeutilitywouldgenerateafilenamedpage1.aspx.cdcab7d2.compiled(withthehashcode varying)thatcontainedthefollowingXML:TheothermajordecisionyouhavetomakewhenpublishingaWebsitewiththisutilityisthegranularityofthepackagingofthegeneratedassemblies.Youcaneithercreateaseparateassemblyforeachdirectoryinyoursiteorcreateaseparateassemblyforeachcompilablefileinyoursite(.aspx,.ascx,.asax,andsoon.)bycheckingtheUsefixednaming
