南京邮电大学
毕业设计(论文)外文资料翻译
学院
专业
学生姓名
班级学号
外文出处
附件：1.外文资料翻译译文；2.外文原文
指导教师评价：
1．翻译内容与课题的结合度：□优□良□中□差2．翻译内容的准确、流畅：□优□良□中□差3．专业词汇翻译的准确性：□优□良□中□差4．翻译字符数是否符合规定要求：□符合□不符合
指导教师签名：
年月日
附件1：外文资料翻译译文
非常https://www.doczj.com/doc/d613446203.html,
1.1Web 部署项目
当ASP 第一次发布时，Web 编程还比较困难，因为需要 IIS 来处理 ASP 页。后来，https://www.doczj.com/doc/d613446203.html, 2.0 和 Visual Studio? 2005 通过引入网站开发模型使一切工作都变得容易了。借助该网站模型，您不必在 Visual Studio 中创建新项目，而是可以指向一个目录并开始编写网页和代码。此外，您还可以使用内置的 https://www.doczj.com/doc/d613446203.html, Development Server 快速测试站点，https://www.doczj.com/doc/d613446203.html, Development Server 将 https://www.doczj.com/doc/d613446203.html, 寄宿在一个本地进程中，并消除了必须安装 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) 可从https://www.doczj.com/doc/d613446203.html,/vstudio/support/vs2005sp1 下载。
WAP 可替代与 Visual Studio .NET 2005 Web 项目模型非常接近的网站模型。新的WAP 模型会在生成过程中编译所有源代码文件，并在本地的 /bin 目录中生成一个用于部署的程序集。WAP 还使得增量采用 https://www.doczj.com/doc/d613446203.html, 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 文件，而只发布二进制程序集（以及配置文件和静态内容）。不过，如果没有物理文件，https://www.doczj.com/doc/d613446203.html, 将无法确定哪些类要用于哪些端点请求。例如，如果您的应用程序收到一个请求 Page1.aspx 的请求，而您已经使用了不可更新的二进制部署，则磁盘上很可能没有任何 Page1.aspx 文件，并且现有配置文件中没有任何内容来指示部署到 /bin 目录的程序集集合中哪个类应是该请求的实际处理程序。为弥补这一缺陷，编译过程还将生成一个 .compiled 文件集合，这些文件以简单的 XML 格式包含端点-类型映射和文件依赖关系信息，同时这些文件必须与所部署站点的 /bin 目录中的二进制程序集一起发布。例如，如果应用程序中原来有一个名为 Page1.aspx 的页，则 aspnet_compiler.exe 实用工具会生成一个名为
https://www.doczj.com/doc/d613446203.html,piled（哈希代码不定）的文件，其中包含以下 XML：
virtualPath="/SampleWebSite/Page1.aspx" hash="8a8da6c5a" filehash="42c4a74221152888" flags="110000" assembly="App_Web_aq9bt8mj" type="ASP.page1_aspx">
使用此实用工具发布网站时必须作出的另一个重要决定是确定生成的程序集的打包粒度。通过选中“使用固定命名和单页程序集”（或在 aspnet_compiler.exe 命令行实用工具中使用 -fixednames），既可为站点中的每个目录创建单独的程序集，又可为站点中的每个可编译文件创建单独的程序集。作出该决定并不像您可能想像的那么容易，因为每个选项都有其潜在问题。如果决定不使用 -fixednames 选项，则每次发布应用程序时都会生成一组全新的程序集，并且它们的名称与之前发布的程序集不同。这意味着部署更加复杂，因为在部署新的程序集之前必须删除主运行服务器上所有以前发布的程序集，否则在处理下一个请求时将生成冗余的类定义错误。使用 -fixednames 选项可以解决此问题，因为每个文件都将与命名清晰的程序集对应，而这些程序集在一次编译和下次编译中不会发生变化。不过，如果站点规模较大，则为每个网页、控件和母版页分别生成单独的程序集，很明显意味着您要管理成百上千个程序集的发布。Web 部署项目非常圆满地解决了部署中程序集粒度这一问题，如下所示。
您还可以将程序集签名引入编译过程，以便创建具有强名称的不同版本的程序集，如果需要这也适用于全局程序集缓存 (GAC) 中的部署。通过使用 -aptca 选项，您可以使用程序集级别的属性 AllowPartiallyTrustedCallers 来标记生成的程序集，在将任何程序集部署到 GAC 并且以低等或中等信任级别运行 https://www.doczj.com/doc/d613446203.html, 的情况下，这是必要的。（请注意，此属性应仅应用于已证明不会暴露任何安全漏洞的程序集，因为如有漏洞，使用此属性可能招致引诱攻击。）
有关发布站点的另一个细节是如果决定使用 Web 应用程序项目而不使用网站模型，则“生成”|“发布”对话框的外观将大不相同。Web 应用程序项目假定您希望将应用程序发布为可更新的 .as*x 文件和预编译的源文件（开发中它所使用的同一模型），因此仅针对二进制的部署选项不可用。此实用工具实质上更接近于“复制网站”实用工具（随网站一起提供）而不是“发布网站”实用工具，因为它需要复制由标准生成过程生成的文件。
从技术上讲，即使您使用 Web 应用程序项目，也不会限制您使用仅针对二进制（不可更新）的部署。其实，WAP 生成的输出是一个有效的网站，然后您可以传递
aspnet_compiler.exe 实用工具来生成创建二进制部署。幸运的是，您只是不能从 Web 部
署项目调整过的 Visual Studio 2005 界面调用它而已。
Web 部署项目
那么迄今为止所有现有的编译和部署选项中缺少什么呢？主要缺少两种功能：控制程序集命名（特别是为了进行部署）的功能，以及将所有输出的程序集合并为一个程序集从而简化部署的功能。Web 部署项目可以解决这两个问题。但或许更重要的是，它们还与网站应用程序和 Web 应用程序项目的部署问题中的许多遗留问题有关。
它们的核心是，Web 部署项目（可从 https://www.doczj.com/doc/d613446203.html,/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 实用工具，https://www.doczj.com/doc/d613446203.html, 2.0 的原始版本部分地实现了开发和部署之间的这种独立性，但由于执行部署时的各种约束从未完全实现。Web 部署项目则已完全实现了开发和部署的分离，有关应用程序如何生成的决定将不再影响部署选择。
合并程序集
Web 部署项目的功能主要是对通过 MSBuild 任务和新界面提供的现有实用工具进行重新打包，但除此之外还提供了几个全新功能。其中最引人关注的功能是程序集合并功能。
安装 Web 部署项目时，您会发现安装目录（默认情况下
是 %PROGRAMFILES%\MSBuild\Microsoft\WebDeployment\v8.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 的最新版本可从 https://www.doczj.com/doc/d613446203.html,/~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，并按如下方式填充：
name="sales_dsn"/> 接下来，您可以对由 Web 部署项目添加的 MSBuild 脚本进行配置，以说明应替换主web.config 文件中的哪些配置部分以及将提供替换内容的源文件。您可以手动修改脚本，但 Visual Studio 中生成脚本的属性页提供的漂亮界面可以为您代劳。在此例中，您是在设置调试解决方案配置的属性，因此选中“启用 Web.config 文件部分替换”选项并指定要随该文件一起替换为相应内容的部分： connectionStrings=debugconnectionstrings.config 您可使用同一对话框页以相应的文件来设置发布解决方案配置（以及我们已定义的任何其他配置）的配置替换。 在随后运行生成脚本时，ReplaceConfigSections 任务会从任何关联的配置文件中提取内容，并替换相应配置部分的内容，同时创建一个放到部署目录的新 web.config 文件。这种配置文件替换功能意味着您可以借助由源代码管理进行版本控制的文本文件，以一种易于管理的方式来维护部署环境之间的配置差异，并且不必使用提醒您在部署时更改连接字符串的粘滞便笺。应予以强调的是，此功能适用于配置文件的任何部分，包括自定义部分，因此如果其他配置部分（例如，appSettings）有差异，您也可以使用此生成任务轻松指定这些差异。 创建可重用用户控件 Web 部署项目有一个有趣的附带应用程序，该应用程序解决了一个已困扰 https://www.doczj.com/doc/d613446203.html, 开发人员多年的问题，即如何创建可重用用户控件以便进行跨应用程序共享。用户控件实质上就是复合的自定义控件，其子控件位于 .ascx 文件中。能够将设计器用于布局控件和添加处理程序对于大多数开发人员来说都是一个巨大帮助，因为在感觉上这和生成网页几乎完全相同，不同的是得到的 .ascx 文件可作为控件包含在任何网页中。而一直存在的不足是需要在应用程序的目录中保留实际的 .ascx 文件才能真正使用它。尽管已有用于实现跨应用程序共享 .ascx 控件的技术，但这些技术通常都涉及许多繁琐事务（如在应用程序之间创建共享虚拟目录或在请求时搜集由 https://www.doczj.com/doc/d613446203.html, 生成的临时程序集），并且从未让人感到满意。 版本 2.0 中引入的 aspnet_compiler.exe 实用工具提供了一个比较好的解决方案。借助此编译器，您可以创建一个仅由用户控件组成的网站，并以不可更新模式发布该站点，以便生成可重用程序集。获得生成的程序集后，您可以将其部署到任何 Web 应用程序并像引用自定义控件那样引用该用户控件（而不是像针对 .ascx 文件那样使用 src 属性）。此技术的唯一缺点是，您要么必须接受由编译过程生成的随机命名程序集，要么必须选中编译器中的 fixednames 选项，以便为站点中的每个母版页各生成名称固定的程序集（而不是为整个集合只生成一个程序集）。 Web 部署项目提供了用于创建真正可重用的用户控件程序集的决定性步骤。您可以使用只包含用户控件的网站，并通过添加 Web 部署项目来创建具有所选名称的单一输出程序集。创建一个要部署到 GAC 的签名程序集会更简单直接，这样无需在每个 /bin 目录中重新部署该程序集即可实现跨多个应用程序的控件共享。 Web 部署项目的推出令人非常满意地完善了用于部署 https://www.doczj.com/doc/d613446203.html, 应用程序的工具集。现在可以用从所有源到所有二进制的任何方式部署应用程序，并且可以完全控制二进制程序集的生成、打包和命名。此外，Web 部署项目还提供了一个解决方案以便根据目标版本替换配置文件的各部分，并解决了可重用用户控件的分发问题。正在构建和部署 https://www.doczj.com/doc/d613446203.html, 应用程序的任何人肯定都会发现 Web 部署项目的某些方面非常有用，足以吸引他们立即开始使用 Web 部署项目 1.2使用 AJAX Extensions 客户端进行 Web 服务调用 从根本上讲，https://www.doczj.com/doc/d613446203.html, 自始至终都是一项服务器端技术。当然，在某些情况下 https://www.doczj.com/doc/d613446203.html, 会生成客户端 JavaScript，特别是在验证控件中以及在新推出的 Web 部件基础结构中，但它通常只是简单地将客户端属性转换成客户端行为。作为开发人员，在收到下一个 POST 请求之前不必考虑与客户端进行交互。对于需要使用客户端 JavaScript 和 DHTML 构建更具交互性的页面的开发人员而言，则需要在 https://www.doczj.com/doc/d613446203.html, 2.0 脚本回调功能提供的一些帮助下自己编写代码。这一情况在去年得到了彻底改变。 在 2005 年 9 月的 Microsoft 在 Microsoft 专业开发人员大会上发布了一个新的https://www.doczj.com/doc/d613446203.html, 插件（代号为“Atlas”），主要是为了充分利用客户端 JavaScript、DHTML 和XMLHttpRequest 对象。其目的是帮助开发人员创建更具交互性的支持 AJAX 的 Web 应用程序。此框架从此更名为正式名称 Microsoft? AJAX Library 和 https://www.doczj.com/doc/d613446203.html, 2.0 AJAX Extensions，它提供了许多出色的功能，包括客户端数据绑定、DHTML 动画和行为以及使用 UpdatePanel 实现的完善的对客户端 POST 回调的拦截。这些功能中的许多功能依赖的是以易于通过客户端 JavaScript 调用进行分析和交互的形式从服务器异步检索数据 的能力。本月专栏的主题便是这一新的非常有用的能力，即在支持 https://www.doczj.com/doc/d613446203.html, 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 服务端点，这也使目前面向服务的应用程序变得可行。 https://www.doczj.com/doc/d613446203.html, 2.0 AJAX Extensions 使得在浏览器中运行的客户端 JavaScript 实现了无缝的、与 Web 服务完全相同的代理生成体验。您可以编写一个在您的服务器上承载 的 .asmx 文件，并通过一个客户端 JavaScript 类调用该服务上方法。例如，图 1 显示了一个简单的 .asmx 服务，该服务实现了模拟的股票报价检索（使用随机数据）。 除了标准的 .asmx Web 服务属性外，此服务还增添了 ScriptService 属性，使其同样可适用于 JavaScript 客户端。如果此 .asmx 文件部署在支持 https://www.doczj.com/doc/d613446203.html, AJAX 的 Web 应用程序中，您可以通过为您的 .aspx 文件中的 ScriptManager 控件添加ServiceReference，从 JavaScript 调用服务的方法（当您使用支持 https://www.doczj.com/doc/d613446203.html, 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 service MsdnMagazine.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 服务中。 请记住，这些客户端代理只能由 https://www.doczj.com/doc/d613446203.html, .asmx 端点、Windows Communication Foundation .svc 端点或直接内嵌在页面中的 WebMethod 生成，而且不是调用任意 Web 服务的通用机制。实际上，对于基本的 XmlHTTPRequest 对象有一般性限制，请求的范围仅限于加载页面的域（出于安全的原因），因此这一做法无法用于调用任意 Web 服务，无论客户端代理是否支持此操作。如果您发现需要调用外部 Web 服务，最好在您调用外部 Web 服务的 .NET 代理类（使用 wsdl.exe 或 Visual Studio 中的“添加 Web 引用”生成）的应用程序中设置一个桥接的 .asmx 端点。 工作原理 您可以采用标准的 .asmx Web 服务，几乎不做任何更改即可在浏览器中通过客户端JavaScript 对其进行访问，乍看起来有些匪夷所思。秘密就在于注册了一个新的 .asmx HTTP 处理程序，并将其添加到了每个支持 https://www.doczj.com/doc/d613446203.html, AJAX 的网站的配置文件中： type="Microsoft.Web.Services.ScriptHandlerFactory" validate="false"/> 如果对一个 .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.StockQuoteService.prototype={ GetStockQuote:https://www.doczj.com/doc/d613446203.html,._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":"ABC"} Response: 51 这当然不是您在调用 .asmx Web 服务时所习惯看到的标准 XML 格式，因为 .asmx 端点在构建时已序列化到 XML 中，所以 https://www.doczj.com/doc/d613446203.html, 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 随 https://www.doczj.com/doc/d613446203.html, 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 对象（正如前面定义的）并对其属性进行相应的修改。（本期的代码下载部分包含有此例附带的 https://www.doczj.com/doc/d613446203.html, 页面。） 如果您选择在您的客户端脚本中使用 XML，该选项仍然可用。除了在定义 Web 服务时使用的标准 WebMethod 属性外，Microsoft.Web.Script.Services 命名空间中还有一个名为 ScriptMethod 的新属性，它具有 ResponseFormat 特性，该特性可设置为 Json 或 Xml（默认值为 Json）。 namespace PS { [ScriptService] [WebService(Namespace = "https://www.doczj.com/doc/d613446203.html,/ws")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] public class StockQuoteService : WebService { [WebMethod] public int GetStockQuote(string symbol) { return (new Random()).Next(0, 120); } } } 这样，序列化的响应将为： 当您通过客户端 JavaScript 调用此方法来处理 XML 响应时，怎样选择由您自己决定。如果您计划对其执行转换，或者已经在使用 MSXML，那么这会非常有用。 总结 有必要指出的是，https://www.doczj.com/doc/d613446203.html, 2.0 AJAX Extensions 提供了两个预先构建的服务，用于通过客户端代码访问特定 https://www.doczj.com/doc/d613446203.html, 2.0 应用程序服务，它们是：ProfileService 和AuthenicationService。使用这两个客户端代理类，您可以为单个客户端设置和检索配置文件值，并完全在客户端脚本中执行身份验证（通过默认的成员资格提供程序）和授予身份验证 cookies。 尽管许多有关 https://www.doczj.com/doc/d613446203.html, 2.0 AJAX Extensions 的讨论和演示都偏重于介绍那些使用户界面具备更高响应能力的漂亮控件，但是能够直接通过客户端 JavaScript 调用 Web 服务是最吸引人、最实用的功能之一。凭借完善的 .NET Framework/JSON 序列化程序、与熟悉的 .asmx Web 服务的直接集成、对批处理的支持和自动生成的与外部 Web 服务的桥接，如此全面且深入地支持 Web 服务可能会使这一功能成为所有功能中最吸引人的功能。 附件2：外文原文 Extreme https://www.doczj.com/doc/d613446203.html, 1.1Web Deployment Projects When ASP was first released, Web programming was more difficult because you needed IIS to serve your ASP pages. Later, https://www.doczj.com/doc/d613446203.html, 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 https://www.doczj.com/doc/d613446203.html, Development Server, which hosts https://www.doczj.com/doc/d613446203.html, in a local process and obviates the need to install IIS to begin developing. The beauty of the Web site model is that you can develop your Web application without thinking about packaging and deployment. Need another class? Add a .cs file to the App_Code directory and start writing. Want to store localizable strings in a resource file? Add a .resx file to the App_GlobalResources directory and type in the strings. Everything just works; you don't have to think about the compilation and deployment aspect at all. When you are ready to deploy, you have several options. The simplest choice is to copy your files to a live server and let everything be compiled on-demand (as it was in your test environment). The second option is to use the aspnet_compiler.exe utility and precompile the application into a binary release, which leaves you nothing but a collection of assemblies, static content, and configuration files to push to the server. The third option is to again use aspnet_compiler.exe, but to create an updateable binary deployment where your .as*x files remain intact (and modifiable) and all of your code files are compiled into binary assemblies. This seems to cover every possible scenario, leaving the developer to focus simply on writing the Web application, with packaging and deployment decisions to be made later when the application is actually deployed. There was a fair amount of backlash against this model, however, especially from developers who were used to their Web projects being real projects, specified in real project files, that let you inject pre-and post-build functions, exclude files from the build process, move between debug and release builds with a command-line switch, and so on. In response, Microsoft quickly introduced the Web Application Project or WAP, initially released as an add-in to Visual Studio 2005, and now included in Visual Studio 2005 Service available for download from https://www.doczj.com/doc/d613446203.html,/vstudio/support/vs2005sp1. WAP provides an alternative to the Web site model that is much closer to the Visual Studio .NET 2005 Web Project model. The new WAP model compiles all of the source code files during the build process and generates a single assembly in the local /bin directory for deployment. WAP also makes it much easier to incrementally adopt the new partial class codebehind model introduced in https://www.doczj.com/doc/d613446203.html, 2.0 because you can now open a Visual Studio .NET 2003 project and only your .sln and .csproj (or .vbproj) files will be modified during the conversion. You can then convert each file and its codebehind class to the new partial class model independently of any other file in the project (by right-clicking on the file in the Solution Explorer and selecting Convert to Web Application), or just leave them using the old model. This is in contrast to converting a Visual Studio .NET 2003 Web project to the Web site model, which converts all files at once and does not support incremental adoption. Finally, there is a new project type called Web Deployment Projects (the main topic of this column), which introduces myriad additional deployment options for both Web site projects and Web Application Projects. Web Deployment Projects fill the remaining holes in the deployment options for both Web site apps and Web Application Projects and make it possible to implement practically any deployment scenario in a simple and extensible way. To understand exactly what this new project type adds, let's first review what we had before Web Deployment Projects were available. When you build an application using the Web site model, you have the option of precompiling the site for deployment. You can access the precompilation utility through the Build | Publish menu in Visual Studio 2005 or directly through the command-line utility aspnet_compiler.exe. Figure 1 shows the interface to this tool exposed by Visual Studio. The first decision you have to make when using the publish utility is whether you want your .as*x files to be updatable once deployed (use the "Allow this precompiled site to be updatable" option of -u switch in the aspnet_compiler.exe command-line utility). This decision hinges on whether you want to be able to make minor changes to your pages once deployed without having to go through the entire deployment process again. You may, in fact, want to explicitly disallow any modifications to the deployed pages and require that all modifications go through the standard deployment (and hopefully testing) process, in which case publishing the site as not updatable is the proper choice. When a site is published as not updatable, it is possible to completely remove all .as*x files and publish only binary assemblies (plus configuration files and static content). However, without the physical files in place, it is impossible for https://www.doczj.com/doc/d613446203.html, to tell which classes to use for which endpoint requests. For example, if a request comes into your application for Page1.aspx and you have used non-updatable binary deployment, there very well may not be any Page1.aspx file on disk, and there is nothing in the existing configuration files to indicate which class in the collection of assemblies deployed to the /bin directory should actually be the handler for this request. To remedy this, the compilation process will also generate a collection of .compiled files that contain endpoint-to-type mapping and file dependency information in a simple XML format, and these files must be published along with the binary assemblies in the /bin directory of the deployed site. As an example, if you did have a page named Page1.aspx in your application, the aspnet_compiler.exe utility would generate a file named https://www.doczj.com/doc/d613446203.html,piled (with the hash code varying) that contained the following XML: virtualPath="/SampleWebSite/Page1.aspx" hash="8a8da6c5a" filehash="42c4a74221152888" flags="110000" assembly="App_Web_aq9bt8mj" type="ASP.page1_aspx"> The other major decision you have to make when publishing a Web site with this utility is the granularity of the packaging of the generated assemblies. You can either create a separate assembly for each directory in your site or create a separate assembly for each compilable file in your site (.aspx, .ascx, .asax, and so on.) by checking the Use fixed naming and single page assemblies (or -fixednames in the aspnet_compiler.exe command-line utility). This decision is not as obvious as you might think, as each option has its own potential issues. If you elect to not use the -fixednames option, then every time you publish your application a completely new set of assemblies will be generated, with completely different names from the ones published earlier. This means that deployment is trickier because you must take care to delete all of the previously published assemblies on the live server before deploying the new assemblies or you'll generate redundant class definition errors on the next request. Using the -fixednames option will resolve this problem as each file will correspond to a distinctly named assembly that will not change from one compilation to the next. If you have a large site, however, generating a separate assembly for each page, control, and Master Page can easily mean managing the publication of hundreds of assemblies. It is this problem of assembly granularity in deployment that Web Deployment Projects solve in a much more satisfying way, as you will see. You can also introduce assembly signing into the compilation process to create strong-named, versioned assemblies, suitable for deployment in the Global Assembly Cache (GAC) if needed. You can mark the generated assemblies with the assembly-level attribute AllowPartiallyTrustedCallers using the -aptca option, which would be necessary if you did deploy any assemblies to the GAC and were running https://www.doczj.com/doc/d613446203.html, at a low or medium level of trust. (Keep in mind that this attribute should only be applied to assemblies that have been shown not to expose any security vulnerabilities, as using it with a vulnerability could expose a luring attack.) One other detail about publishing your site is that if you do elect to use Web Application Projects instead of the Web site model, the Build | Publish dialog box will look quite different, as shown in Figure 2. Web Application Projects assume that you want to publish the application as updatable .as*x files and precompiled source files (the same model it uses in development), so the binary-only deployment options are not available. This utility is really closer in nature to the Copy Web site utility available with Web sites than it is to the Publish Web Site utility since it involves copying files produced by the standard build process. Technically you are not restricted from using binary-only (non-updatable) deployment, even if you are using Web Application Projects. If you think about it, the output of the build of a WAP is a valid Web site, which you can then pass through the aspnet_compiler.exe utility to generate create a binary deployment. You just can't invoke it from the Visual Studio 2005 interface which, fortunately, Web Deployment Projects rectify. So what's missing from the existing compilation and deployment options presented so far? Primarily two things: the ability to control the naming of assemblies, especially for deployment purposes, and the ability to consolidate all of the output assemblies into a single assembly for simplified deployment. Web Deployment Projects solve both of these problems. Perhaps even more significantly, however, they also tie up a lot of loose ends in the deployment story that existed with Web site applications and Web Application Projects. At their core, Web Deployment Projects (available for download at https://www.doczj.com/doc/d613446203.html,/aa336619.aspx) represent just another type of project you add to your solution. Like all Visual Studio project files, Web deployment projects are MSBuild scripts that can be compiled directly in the IDE or run from the command line. Instead of specifying a collection of source code files to compile, however, Web Deployment Projects contain build commands to compile and package Web sites (or Web Application Projects). This means that they will invoke the aspnet_compiler.exe utility (among others) to create a deployment of a particular Web application. Web Deployment Projects are shipped as a Visual Studio add-in package that includes an easy-to-use menu item for injecting new projects and a complete set of property pages to control all of the available settings. To add one to an existing application, right-click on an existing Web site (or Web Application Project) and select the Add Web Deployment Project item as shown in Figure 3. This will add a new .wdproj file containing an MSBuild script to your solution, which will generate a deployment of the application you created it from. Once the Web Deployment Project is part of your solution, you can access the property pages of the project file to control exactly what the project does for you, as shown in Figure 4. The default setting for a new deployment project is to deploy the application in updatable mode, with all the .as*x files intact, and the source files compiled into a single assembly deployed in the top-level /bin directory. These deployment projects work the same regardless of whether the source application is using the Web site model or the Web Application Project model, which means that you can now select either development model without impacting your deployment options. One of the most significant features of Web Deployment Projects is the ability to configure the deployment to be all binary (not updatable) in the form of a single assembly, the name of which you can choose. Using this model of deployment means that you can update your entire site merely by pushing a single assembly to the /bin directory of your live site, and not concern yourself with deleting existing assemblies prior to deploying or dealing with a partially deployed site causing errors. It is still necessary to deploy the .compiled files for the endpoint mappings, but these files only change when you add, delete, or move pages in your site. Web Deployment Projects provide flexibility in deployment and let you make packaging and deployment decisions independently of how you actually built your Web applications. This independence between development and deployment was partially achieved in the original release of https://www.doczj.com/doc/d613446203.html, 2.0 with the aspnet_compiler.exe utility, but never fully realized because of the constraints imposed when performing the deployment. With Web Deployment Projects, the separation between development and deployment is now complete, and your decision about how to build your applications will no longer impact your deployment choices. Merging Assemblies Much of what Web Deployment Projects provide is just a repackaging of existing utilities exposed via MSBuild tasks and a new interface, but there are also a couple of completely new features included. The most intriguing is the ability to merge assemblies. When you install Web Deployment Projects, you will find an executable called aspnet_merge.exe in the installation directory. This executable is capable of taking the multi-assembly output of a precompiled site and merging the assemblies into one. This is the utility that is incorporated into your build script if you select the merge option in a Web Deployment Project. As an example of what is possible with this utility, consider the output of a precompiled Web site, run without the updatable switch, shown in Figure 5. The source application for this output contained two subdirectories, a top-level global.asax file, a class defined in App_Code, and a user control. The end result of the compilation is five different assemblies and a collection of .compiled files. If you run the aspnet_merge.exe utility on this directory with the -o switch to request a single assembly output, shown at the bottom of Figure 5, the result is a much more manageable single assembly named whatever you specify. Although the aspnet_merge.exe utility and the corresponding MSBuild task that ship with Web Deployment Projects are new, the underlying technology for merging assemblies has actually been around since the Microsoft? .NET Framework 1.1 in the form of a utility made available from Microsoft Research called ILMerge, the latest version of which is available for download from https://www.doczj.com/doc/d613446203.html,/~mbarnett/ILMerge.aspx. This utility is directly incorporated into aspnet_merge.exe and does all the heavy lifting involved with merging assemblies. If you think about it, the merging of assemblies is a rather complicated task. You need to take into consideration signing, versioning, and other assembly-level attributes, embedded resources, and XML documentation, as well as manage the details of clashing type names, and so on. The ILMerge utility manages all of these details for you, with switches to control various decisions about the process. It also gives you the ability to transform .exe assemblies into .dll assemblies for packaging purposes. As an example, suppose you have three assemblies: a.dll, b.dll, and c.exe which you would like to merge into a single library assembly. As long as there were no conflicts in typenames, the following command line would generate a new library, d.dll with all of the types defined in a.dll, b.dll, and c.exe: ilmerge.exe /t:library /ndebug /out:d.dll a.dll b.dll c.exe Pluggable Configuration Files The other completely new feature that comes with Web Deployment Projects is the ability to create pluggable configuration files. It is a common problem when deploying Web applications to find a way to manage the differences in your configuration files between development and deployment. For example, you may have a local test database to run your site, have another database used by a staging server, and yet another used by the live server. If you are storing your connection strings in web.config (typically in the connectionStrings section), then you need some way of modifying those strings when the application is pushed out to a staging server or to a production machine. Web Deployment Projects offer a clean solution to this problem with a new MSBuild task called ReplaceConfigSections. This task allows you to specify independent files that store the contents of a particular configuration section independently based on solution configurations. For example, you might create a debugconnectionstrings.config file to store the debug version of our connectionStrings configuration section that looked like this: 外文出处： 《Exploiting Software How to Break Code》By Greg Hoglund, Gary McGraw Publisher : Addison Wesley Pub Date : February 17, 2004 ISBN : 0-201-78695-8 译文标题： JDBC接口技术 译文： JDBC是一种可用于执行SQL语句的JavaAPI（ApplicationProgrammingInterface应用程序设计接口）。它由一些Java语言编写的类和界面组成。JDBC为数据库应用开发人员、数据库前台工具开发人员提供了一种标准的应用程序设计接口，使开发人员可以用纯Java语言编写完整的数据库应用程序。 一、ODBC到JDBC的发展历程 说到JDBC，很容易让人联想到另一个十分熟悉的字眼“ODBC”。它们之间有没有联系呢？如果有，那么它们之间又是怎样的关系呢？ ODBC是OpenDatabaseConnectivity的英文简写。它是一种用来在相关或不相关的数据库管理系统（DBMS）中存取数据的，用C语言实现的，标准应用程序数据接口。通过ODBCAPI，应用程序可以存取保存在多种不同数据库管理系统（DBMS）中的数据，而不论每个DBMS使用了何种数据存储格式和编程接口。 1．ODBC的结构模型 ODBC的结构包括四个主要部分：应用程序接口、驱动器管理器、数据库驱动器和数据源。应用程序接口：屏蔽不同的ODBC数据库驱动器之间函数调用的差别，为用户提供统一的SQL编程接口。 驱动器管理器：为应用程序装载数据库驱动器。 数据库驱动器：实现ODBC的函数调用，提供对特定数据源的SQL请求。如果需要，数据库驱动器将修改应用程序的请求，使得请求符合相关的DBMS所支持的文法。 数据源：由用户想要存取的数据以及与它相关的操作系统、DBMS和用于访问DBMS的网络平台组成。 虽然ODBC驱动器管理器的主要目的是加载数据库驱动器，以便ODBC函数调用，但是数据库驱动器本身也执行ODBC函数调用，并与数据库相互配合。因此当应用系统发出调用与数据源进行连接时，数据库驱动器能管理通信协议。当建立起与数据源的连接时，数据库驱动器便能处理应用系统向DBMS发出的请求，对分析或发自数据源的设计进行必要的翻译，并将结果返回给应用系统。 2．JDBC的诞生 自从Java语言于1995年5月正式公布以来，Java风靡全球。出现大量的用java语言编写的程序，其中也包括数据库应用程序。由于没有一个Java语言的API，编程人员不得不在Java程序中加入C语言的ODBC函数调用。这就使很多Java的优秀特性无法充分发挥，比如平台无关性、面向对象特性等。随着越来越多的编程人员对Java语言的日益喜爱，越来越多的公司在Java程序开发上投入的精力日益增加，对java语言接口的访问数据库的API 的要求越来越强烈。也由于ODBC的有其不足之处，比如它并不容易使用，没有面向对象的特性等等，SUN公司决定开发一Java语言为接口的数据库应用程序开发接口。在JDK1．x 版本中，JDBC只是一个可选部件，到了JDK1．1公布时，SQL类包（也就是JDBCAPI） 毕业设计（论文）外文文献翻译 文献、资料中文题目：软件开发概念和设计方法文献、资料英文题目： 文献、资料来源： 文献、资料发表（出版）日期： 院（部）： 专业： 班级： 姓名： 学号： 指导教师： 翻译日期： 2017.02.14 外文资料原文 Software Development Concepts and Design Methodologies During the 1960s, ma inframes and higher level programming languages were applied to man y problems including human resource s yste ms,reservation s yste ms, and manufacturing s yste ms. Computers and software were seen as the cure all for man y bu siness issues were some times applied blindly. S yste ms sometimes failed to solve the problem for which the y were designed for man y reasons including: ?Inability to sufficiently understand complex problems ?Not sufficiently taking into account end-u ser needs, the organizational environ ment, and performance tradeoffs ?Inability to accurately estimate development time and operational costs ?Lack of framework for consistent and regular customer communications At this time, the concept of structured programming, top-down design, stepwise refinement，and modularity e merged. Structured programming is still the most dominant approach to software engineering and is still evo lving. These failures led to the concept of "software engineering" based upon the idea that an engineering-like discipl ine could be applied to software design and develop ment. Software design is a process where the software designer applies techniques and principles to produce a conceptual model that de scribes and defines a solution to a problem. In the beginning, this des ign process has not been well structured and the model does not alwa ys accurately represent the problem of software development. However,design methodologies have been evolving to accommo date changes in technolog y coupled with our increased understanding of development processes. Whereas early desig n methods addressed specific aspects of the 外文翻译 专业机械设计制造及其自动化学生姓名刘链柱 班级机制111 学号1110101102 指导教师葛友华 外文资料名称： Design and performance evaluation of vacuum cleaners using cyclone technology 外文资料出处：Korean J. Chem. Eng., 23(6), (用外文写) 925-930 (2006) 附件： 1.外文资料翻译译文 2.外文原文 应用旋风技术真空吸尘器的设计和性能介绍 吉尔泰金，洪城铱昌，宰瑾李， 刘链柱译 摘要：旋风型分离器技术用于真空吸尘器 - 轴向进流旋风和切向进气道流旋风有效地收集粉尘和降低压力降已被实验研究。优化设计等因素作为集尘效率，压降，并切成尺寸被粒度对应于分级收集的50％的效率进行了研究。颗粒切成大小降低入口面积，体直径，减小涡取景器直径的旋风。切向入口的双流量气旋具有良好的性能考虑的350毫米汞柱的低压降和为1.5μm的质量中位直径在1米3的流量的截止尺寸。一使用切向入口的双流量旋风吸尘器示出了势是一种有效的方法，用于收集在家庭中产生的粉尘。 摘要及关键词：吸尘器; 粉尘; 旋风分离器 引言 我们这个时代的很大一部分都花在了房子，工作场所，或其他建筑，因此，室内空间应该是既舒适情绪和卫生。但室内空气中含有超过室外空气因气密性的二次污染物，毒物，食品气味。这是通过使用产生在建筑中的新材料和设备。真空吸尘器为代表的家电去除有害物质从地板到地毯所用的商用真空吸尘器房子由纸过滤，预过滤器和排气过滤器通过洁净的空气排放到大气中。虽然真空吸尘器是方便在使用中，吸入压力下降说唱空转成比例地清洗的时间，以及纸过滤器也应定期更换，由于压力下降，气味和细菌通过纸过滤器内的残留粉尘。 图1示出了大气气溶胶的粒度分布通常是双峰形，在粗颗粒（>2.0微米）模式为主要的外部来源，如风吹尘，海盐喷雾，火山，从工厂直接排放和车辆废气排放，以及那些在细颗粒模式包括燃烧或光化学反应。表1显示模式，典型的大气航空的直径和质量浓度溶胶被许多研究者测量。精细模式在0.18?0.36 在5.7到25微米尺寸范围微米尺寸范围。质量浓度为2?205微克，可直接在大气气溶胶和 3.85至36.3μg/m3柴油气溶胶。 毕业设计（论文） 外文翻译 题目西安市水源工程中的 水电站设计 专业水利水电工程 班级 学生 指导教师 2016年 研究钢弧形闸门的动态稳定性 牛志国 河海大学水利水电工程学院，中国南京，邮编210098 nzg_197901@https://www.doczj.com/doc/d613446203.html,，niuzhiguo@https://www.doczj.com/doc/d613446203.html, 李同春 河海大学水利水电工程学院，中国南京，邮编210098 ltchhu@https://www.doczj.com/doc/d613446203.html, 摘要 由于钢弧形闸门的结构特征和弹力，调查对参数共振的弧形闸门的臂一直是研究领域的热点话题弧形弧形闸门的动力稳定性。在这个论文中，简化空间框架作为分析模型，根据弹性体薄壁结构的扰动方程和梁单元模型和薄壁结构的梁单元模型，动态不稳定区域的弧形闸门可以通过有限元的方法，应用有限元的方法计算动态不稳定性的主要区域的弧形弧形闸门工作。此外，结合物理和数值模型，对识别新方法的参数共振钢弧形闸门提出了调查，本文不仅是重要的改进弧形闸门的参数振动的计算方法，但也为进一步研究弧形弧形闸门结构的动态稳定性打下了坚实的基础。 简介 低举升力，没有门槽，好流型，和操作方便等优点，使钢弧形闸门已经广泛应用于水工建筑物。弧形闸门的结构特点是液压完全作用于弧形闸门，通过门叶和主大梁，所以弧形闸门臂是主要的组件确保弧形闸门安全操作。如果周期性轴向载荷作用于手臂，手臂的不稳定是在一定条件下可能发生。调查指出:在弧形闸门的20次事故中，除了极特殊的破坏情况下，弧形闸门的破坏的原因是弧形闸门臂的不稳定;此外，明显的动态作用下发生破坏。例如:张山闸，位于中国的江苏省，包括36个弧形闸门。当一个弧形闸门打开放水时，门被破坏了，而其他弧形闸门则关闭，受到静态静水压力仍然是一样的，很明显，一个动态的加载是造成的弧形闸门破坏一个主要因素。因此弧形闸门臂的动态不稳定是造成弧形闸门(特别是低水头的弧形闸门)破坏的主要原是毫无疑问。 I / 11 本科毕业设计外文翻译 <2018届） 论文题目基于WEB 的J2EE 的信息系统的方法研究 作者姓名[单击此处输入姓名] 指导教师[单击此处输入姓名] 学科(专业 > 所在学院计算机科学与技术学院 提交日期[时间 ] 基于WEB的J2EE的信息系统的方法研究 摘要：本文介绍基于工程的Java开发框架背后的概念，并介绍它如何用于IT 工程开发。因为有许多相同设计和开发工作在不同的方式下重复，而且并不总是符合最佳实践，所以许多开发框架建立了。我们已经定义了共同关注的问题和应用模式，代表有效解决办法的工具。开发框架提供：<1）从用户界面到数据集成的应用程序开发堆栈；<2）一个架构，基本环境及他们的相关技术，这些技术用来使用其他一些框架。架构定义了一个开发方法，其目的是协助客户开发工程。 关键词：J2EE 框架WEB开发 一、引言 软件工具包用来进行复杂的空间动态系统的非线性分析越来越多地使用基于Web的网络平台，以实现他们的用户界面，科学分析，分布仿真结果和科学家之间的信息交流。对于许多应用系统基于Web访问的非线性分析模拟软件成为一个重要组成部分。网络硬件和软件方面的密集技术变革[1]提供了比过去更多的自由选择机会[2]。因此，WEB平台的合理选择和发展对整个地区的非线性分析及其众多的应用程序具有越来越重要的意义。现阶段的WEB发展的特点是出现了大量的开源框架。框架将Web开发提到一个更高的水平，使基本功能的重复使用成为可能和从而提高了开发的生产力。 在某些情况下，开源框架没有提供常见问题的一个解决方案。出于这个原因，开发在开源框架的基础上建立自己的工程发展框架。本文旨在描述是一个基于Java的框架，该框架利用了开源框架并有助于开发基于Web的应用。通过分析现有的开源框架，本文提出了新的架构，基本环境及他们用来提高和利用其他一些框架的相关技术。架构定义了自己开发方法，其目的是协助客户开发和事例工程。 应用程序设计应该关注在工程中的重复利用。即使有独特的功能要求，也 Optimum blank design of an automobile sub-frame Jong-Yop Kim a ,Naksoo Kim a,*,Man-Sung Huh b a Department of Mechanical Engineering,Sogang University,Shinsu-dong 1,Mapo-ku,Seoul 121-742,South Korea b Hwa-shin Corporation,Young-chun,Kyung-buk,770-140,South Korea Received 17July 1998 Abstract A roll-back method is proposed to predict the optimum initial blank shape in the sheet metal forming process.The method takes the difference between the ?nal deformed shape and the target contour shape into account.Based on the method,a computer program composed of a blank design module,an FE-analysis program and a mesh generation module is developed.The roll-back method is applied to the drawing of a square cup with the ˉange of uniform size around its periphery,to con?rm its validity.Good agreement is recognized between the numerical results and the published results for initial blank shape and thickness strain distribution.The optimum blank shapes for two parts of an automobile sub-frame are designed.Both the thickness distribution and the level of punch load are improved with the designed blank.Also,the method is applied to design the weld line in a tailor-welded blank.It is concluded that the roll-back method is an effective and convenient method for an optimum blank shape design.#2000Elsevier Science S.A.All rights reserved. Keywords:Blank design;Sheet metal forming;Finite element method;Roll-back method 理工学院毕业设计(论文)外文资料翻译 专业：热能与动力工程 姓名：赵海潮 学号：09L0504133 外文出处：Applied Acoustics, 2010(71):701~707 附件： 1.外文资料翻译译文；2.外文原文。 附件1：外文资料翻译译文 基于一维CFD模型下汽车排气消声器的实验研究与预测Takeshi Yasuda, Chaoqun Wua, Noritoshi Nakagawa, Kazuteru Nagamura 摘要目前，利用实验和数值分析法对商用汽车消声器在宽开口喉部加速状态下的排气噪声进行了研究。在加热工况下发动机转速从1000转/分钟加速到6000转/分钟需要30秒。假定其排气消声器的瞬时声学特性符合一维计算流体力学模型。为了验证模拟仿真的结果，我们在符合日本工业标准（JIS D 1616）的消声室内测量了排气消声器的瞬态声学特性，结果发现在二阶发动机转速频率下仿真结果和实验结果非常吻合。但在发动机高阶转速下（从5000到6000转每分钟的四阶转速，从4200到6000转每分钟的六阶转速这样的高转速范围内），计算结果和实验结果出现了较大差异。根据结果分析，差异的产生是由于在模拟仿真中忽略了流动噪声的影响。为了满足市场需求，研究者在一维计算流体力学模型的基础上提出了一个具有可靠准确度的简化模型，相对标准化模型而言该模型能节省超过90％的执行时间。 关键字消声器排气噪声优化设计瞬态声学性能 1 引言 汽车排气消声器广泛用于减小汽车发动机及汽车其他主要部位产生的噪声。一般而言，消声器的设计应该满足以下两个条件：（1）能够衰减高频噪声，这是消声器的最基本要求。排气消声器应该有特定的消声频率范围，尤其是低频率范围，因为我们都知道大部分的噪声被限制在发动机的转动频率和它的前几阶范围内。（2）最小背压，背压代表施加在发动机排气消声器上额外的静压力。最小背压应该保持在最低限度内，因为大的背压会降低容积效率和提高耗油量。对消声器而言，这两个重要的设计要求往往是互相冲突的。对于给定的消声器，利用实验的方法，根据距离尾管500毫米且与尾管轴向成45°处声压等级相近的排气噪声来评估其噪声衰减性能，利用压力传感器可以很容易地检测背压。 近几十年来，在预测排气噪声方面广泛应用的方法有：传递矩阵法、有限元法、边界元法和计算流体力学法。其中最常用的方法是传递矩阵法（也叫四端网络法）。该方 Section 3 Design philosophy, design method and earth pressures 3.1 Design philosophy 3.1.1 General The design of earth retaining structures requires consideration of the interaction between the ground and the structure. It requires the performance of two sets of calculations: 1）a set of equilibrium calculations to determine the overall proportions and the geometry of the structure necessary to achieve equilibrium under the relevant earth pressures and forces; 2）structural design calculations to determine the size and properties of thestructural sections necessary to resist the bending moments and shear forces determined from the equilibrium calculations. Both sets of calculations are carried out for specific design situations (see 3.2.2) in accordance with the principles of limit state design. The selected design situations should be sufficiently Severe and varied so as to encompass all reasonable conditions which can be foreseen during the period of construction and the life of the retaining wall. 3.1.2 Limit state design This code of practice adopts the philosophy of limit state design. This philosophy does not impose upon the designer any special requirements as to the manner in which the safety and stability of the retaining wall may be achieved, whether by overall factors of safety, or partial factors of safety, or by other measures. Limit states (see 1.3.13) are classified into: a) ultimate limit states (see 3.1.3); b) serviceability limit states (see 3.1.4). Typical ultimate limit states are depicted in figure 3. Rupture states which are reached before collapse occurs are, for simplicity, also classified and 附件1：外文资料翻译译文 包装对食品发展的影响 一个消费者对某个产品的第一印象来说包装是至关重要的，包括沟通的可取性，可接受性，健康饮食形象等。食品能够提供广泛的产品和包装组合，传达自己加工的形象感知给消费者，例如新鲜包装/准备，冷藏，冷冻，超高温无菌，消毒（灭菌），烘干产品。 食物的最重要的质量属性之一，是它的味道，其影响人类的感官知觉，即味觉和嗅觉。味道可以很大程度作退化的处理和/或扩展存储。其他质量属性，也可能受到影响，包括颜色，质地和营养成分。食品质量不仅取决于原材料，添加剂，加工和包装的方法，而且其预期的货架寿命（保质期）过程中遇到的分布和储存条件的质量。越来越多的竞争当中，食品生产商，零售商和供应商；和质量审核供应商有显着提高食品质量以及急剧增加包装食品的选择。这些改进也得益于严格的冷藏链中的温度控制和越来越挑剔的消费者。 保质期的一个定义是：在食品加工和包装组合下，在食品的容器和条件，在销售点分布在特定系统的时间能保持令人满意的食味品质。保质期，可以用来作为一个新鲜的概念，促进营销的工具。延期或保质期长的产品，还提供产品的使用时间，方便以及减少浪费食物的风险，消费者和/或零售商。包装产品的质量和保质期的主题是在第3章中详细讨论。 包装为消费者提供有关产品的重要信息，在许多情况下，使用的包装和/或产品，包括事实信息如重量，体积，配料，制造商的细节，营养价值，烹饪和开放的指示，除了法律准则的最小尺寸的文字和数字，有定义的各类产品。消费者寻求更详细的产品信息，同时，许多标签已经成为多语种。标签的可读性是为视障人士的问题，这很可能成为一个对越来越多的老年人口越来越重要的问题。 食物的选择和包装创新的一个主要驱动力是为了方便消费者的需求。这里有许多方便的现代包装所提供的属性，这些措施包括易于接入和开放，处置和处理，产品的知名度，再密封性能，微波加热性，延长保质期等。在英国和其他发达经济体显示出生率下降和快速增长的一个相对富裕的老人人口趋势，伴随着更加苛 毕业设计（论文） 外文文献翻译 题目：A new constructing auxiliary function method for global optimization 学院： 专业名称： 学号： 学生姓名： 指导教师： 2014年2月14日 一个新的辅助函数的构造方法的全局优化 Jiang-She Zhang，Yong-Jun Wang https://www.doczj.com/doc/d613446203.html,/10.1016/j.mcm.2007.08.007 非线性函数优化问题中具有许多局部极小，在他们的搜索空间中的应用，如工程设计，分子生物学是广泛的，和神经网络训练．虽然现有的传统的方法，如最速下降方法，牛顿法，拟牛顿方法，信赖域方法，共轭梯度法，收敛迅速，可以找到解决方案，为高精度的连续可微函数，这在很大程度上依赖于初始点和最终的全局解的质量很难保证．在全局优化中存在的困难阻碍了许多学科的进一步发展．因此，全局优化通常成为一个具有挑战性的计算任务的研究． 一般来说，设计一个全局优化算法是由两个原因造成的困难：一是如何确定所得到的最小是全球性的（当时全球最小的是事先不知道），和其他的是，如何从中获得一个更好的最小跳．对第一个问题，一个停止规则称为贝叶斯终止条件已被报道．许多最近提出的算法的目标是在处理第二个问题．一般来说，这些方法可以被类?主要分两大类，即：（一）确定的方法，及（ii）的随机方法．随机的方法是基于生物或统计物理学，它跳到当地的最低使用基于概率的方法．这些方法包括遗传算法（GA），模拟退火法（SA）和粒子群优化算法（PSO）．虽然这些方法有其用途，它们往往收敛速度慢和寻找更高精度的解决方案是耗费时间．他们更容易实现和解决组合优化问题．然而，确定性方法如填充函数法，盾构法，等，收敛迅速，具有较高的精度，通常可以找到一个解决方案．这些方法往往依赖于修改目标函数的函数“少”或“低”局部极小，比原来的目标函数，并设计算法来减少该?ED功能逃离局部极小更好的发现． 引用确定性算法中，扩散方程法，有效能量的方法，和积分变换方法近似的原始目标函数的粗结构由一组平滑函数的极小的“少”．这些方法通过修改目标函数的原始目标函数的积分．这样的集成是实现太贵，和辅助功能的最终解决必须追溯到 冷冲模具使用寿命的影响及对策 冲压模具概述 冲压模具--在冷冲压加工中，将材料（金属或非金属）加工成零件（或半成品）的一种特殊工艺装备，称为冷冲压模具（俗称冷冲模）。冲压--是在室温下，利用安装在压力机上的模具对材料施加压力，使其产生分离或塑性变形，从而获得所需零件的一种压力加工方法。 冲压模具的形式很多，一般可按以下几个主要特征分类： １．根据工艺性质分类 （1）冲裁模沿封闭或敞开的轮廓线使材料产生分离的模具。如落料模、冲孔模、切断模、切口模、切边模、剖切模等。 （2）弯曲模使板料毛坯或其他坯料沿着直线（弯曲线）产生弯曲变形，从而获得一定角度和形状的工件的模具。 （3）拉深模是把板料毛坯制成开口空心件，或使空心件进一步改变形状和尺寸的模具。 （4）成形模是将毛坯或半成品工件按图凸、凹模的形状直接复制成形，而材料本身仅产生局部塑性变形的模具。如胀形模、缩口模、扩口模、起伏成形模、翻边模、整形模等。 ２．根据工序组合程度分类 （1）单工序模在压力机的一次行程中，只完成一道冲压工序的模具。 （2）复合模只有一个工位，在压力机的一次行程中，在同一工位上同时完成两道或两道以上冲压工序的模具。 （3）级进模（也称连续模）在毛坯的送进方向上，具有两个或更多的工位，在压力机的一次行程中，在不同的工位上逐次完成两道或两道以上冲压工序的模具。 冲冷冲模全称为冷冲压模具。 冷冲压模具是一种应用于模具行业冷冲压模具及其配件所需高性能结构陶瓷材料的制备方法，高性能陶瓷模具及其配件材料由氧化锆、氧化钇粉中加铝、镨元素构成，制备工艺是将氧化锆溶液、氧化钇溶液、氧化镨溶液、氧化铝溶液按一定比例混合配成母液，滴入碳酸氢铵，采用共沉淀方法合成模具及其配件陶瓷材料所需的原材料，反应生成的沉淀经滤水、干燥，煅烧得到高性能陶瓷模具及其配件材料超微粉，再经过成型、烧结、精加工，便得到高性能陶瓷模具及其配件材料。本发明的优点是本发明制成的冷冲压模具及其配件使用寿命长，在冲压过程中未出现模具及其配件与冲压件产生粘结现象，冲压件表面光滑、无毛刺，完全可以替代传统高速钢、钨钢材料。 冷冲模具主要零件 冷冲模具是冲压加工的主要工艺装备，冲压制件就是靠上、下模具的相对运动来完成的。加工时由于上、下模具之间不断地分合，如果操作工人的手指不断进入或停留在模具闭合区，便会对其人身安全带来严重威胁。 南京理工大学 毕业设计(论文)外文资料翻译 教学点：南京信息职业技术学院 专业：电子信息工程 姓名：陈洁 学号： 014910253034 外文出处：《 Pci System Architecture 》 (用外文写) 附件： 1.外文资料翻译译文；2.外文原文。 指导教师评语： 该生外文翻译没有基本的语法错误，用词准确，没 有重要误译，忠实原文；译文通顺，条理清楚，数量与 质量上达到了本科水平。 签名： 年月日 注：请将该封面与附件装订成册。 附件1：外文资料翻译译文 64位PCI扩展 1.64位数据传送和64位寻址：独立的能力 PCI规范给出了允许64位总线主设备与64位目标实现64位数据传送的机理。在传送的开始，如果回应目标是一个64位或32位设备，64位总线设备会自动识别。如果它是64位设备，达到8个字节（一个4字）可以在每个数据段中传送。假定是一串0等待状态数据段。在33MHz总线速率上可以每秒264兆字节获取（8字节／传送＊33百万传送字／秒），在66MHz总线上可以528M字节／秒获取。如果回应目标是32位设备，总线主设备会自动识别并且在下部4位数据通道上（AD[31::00]）引导，所以数据指向或来自目标。 规范也定义了64位存储器寻址功能。此功能只用于寻址驻留在4GB地址边界以上的存储器目标。32位和64位总线主设备都可以实现64位寻址。此外，对64位寻址反映的存储器目标（驻留在4GB地址边界上）可以看作32位或64位目标来实现。 注意64位寻址和64位数据传送功能是两种特性，各自独立并且严格区分开来是非常重要的。一个设备可以支持一种、另一种、都支持或都不支持。 2.64位扩展信号 为了支持64位数据传送功能，PCI总线另有39个引脚。 ●REQ64#被64位总线主设备有效表明它想执行64位数据传送操作。REQ64#与FRAME#信号具有相同的时序和间隔。REQ64#信号必须由系统主板上的上拉电阻来支持。当32位总线主设备进行传送时，REQ64#不能又漂移。 ●ACK64#被目标有效以回应被主设备有效的REQ64#（如果目标支持64位数据传送），ACK64#与DEVSEL#具有相同的时序和间隔（但是直到REQ64#被主设备有效，ACK64#才可被有效）。像REQ64#一样，ACK64#信号线也必须由系统主板上的上拉电阻来支持。当32位设备是传送目标时，ACK64#不能漂移。 ●AD[64::32]包含上部4位地址／数据通道。 ●C/BE#[7::4]包含高4位命令/字节使能信号。 ●PAR64是为上部4个AD通道和上部4位C/BE信号线提供偶校验的奇偶校验位。 以下是几小结详细讨论64位数据传送和寻址功能。 3.在32位插入式连接器上的64位卡 毕业设计外文资料翻译 设计题目: 译文题目: 太阳能蒸笼 学生姓名： 学号： 专业班级： 指导教师： 正文：外文资料译文附件：外文资料原文 太阳能蒸笼 罗达.斯坦塔食品和营养学助理 许多不同的系统介绍了太阳能炊具。不同的设计有不同的优势。它也表明太阳能灶还处于初级阶段,将有希望有个美好的未来,不仅有助于解决气候变化问题,而且在做一件重要的事,服务许多人的生命。 大部份太阳能炊具有某种形式的反光罩的集中太阳的能量。太阳轮使用不反光但集中太阳能通过创造蒸汽从相对较大的收集器区域,并将其用于一个较小的烹饪区。随着太阳能轮使用蒸汽作为传热媒介,它是一种间接的烹饪系统。这允许一个分裂的烹饪系统,其热太阳能集热器可以放置在某个距离(如在屋顶上)除了烹饪的地方(例如在厨房里)。厨师正在不接触阳光的并且可以用蒸汽,无论高低都方便,可接受的区域。 这使它成为一个非常方便的炊具为大量的食物。使用简单叠加可以蒸煮几样菜，可以煮熟的同时进行。那热气腾腾的过程是非常相似与传统蒸煮过程，应该容易得到各种文化的认可。 太阳所产生的蒸汽也可以被用来热量大的罐炖肉或汤通过引导蒸汽直接进入了液体在它凝聚和释放的热凝。这就引起我做一个温柔的风潮的食品烤干。 在其设计技术,利用太阳船的有效性标准疏散管太阳能集热器可降低成本。 配料系统 可以看出从素描以上基本的想法是很简单的。太阳能收集器里装满了水。因为它具有极高的效率和良好的保温玻璃管的撤离开始沸腾的水会暴露在阳光下时。蒸汽会被引导到蒸笼以灵活的、蒸汽抗性软管。 连续系统 最后更复杂的,因为它必须确信,玻璃管永远不会变干的。一滴滴喂料系统集成式换热器提供了一条连续的淡水来代替水流失为蒸汽。这也防止了重建的盐和污染的太阳能集热器。因为这个系统包含了大量的沸腾的水在玻璃管,它具有使绝对肯定,没有压力,建立该体系。 成本 为了保持成本低，Sun2Steam正在出售一转换工具包可以很容易地安装在一个标准的低成本太阳能集热器。此套将直接来自澳大利亚,而太阳能收集器可直接来源于一个低成本的供应商。 一个太阳能集热器和20管直径和57mm 1.8米长，在中国是可以买到的大约200美元。转换组件包括500万绝缘软管取决于汇率蒸汽将大约200美元。成本增加25%,装船的税负导致的总费用为500美元左右的太阳能船没有安装费用和培训。 这使得轮船进入上部成本支架太阳能炊具。然而所有的材料都要持久和完整的炊具应该很容易超过了一生的10年。炉子可以很容易地帮助准备食物为10人。这使人均成本的太阳能减少至约五十美元。 也有一些额外的好处。太阳轮能生产大约5升的高质量的蒸馏水一天所产生的凝汽。一个可选的转换器将允许生产超过100升的安全、pasteurised饮水每天。报告描述太阳能蒸笼在这里可以找到: 大多数高海拔的烹饪和烘烤的指示不推荐补偿,直到你到达约6000英尺的海拔高度。居住在该地区,并且现在我住在怀俄明,是正确的,我们的高度范围你真正开始注重细微的差别,所以我已经学会补偿烤时和烹饪。 水沸腾时会出现在较低的温度在这里——这是由于减少了空气压力。你不会真正注意到什么大的差异在4000英尺,甚至在6000英尺,唯一的真正的区别是面带最微小的更久一点做饭,和糙米试你的耐心一点超过正常(以接近一个小时做饭,而不是通常的40分钟)。糖果还可以要求较长的沸腾时期达到各种球类或裂缝阶段。最引人注目的差异在这个高度是烤面包。蛋糕是一个倾向于看起来更温柔,更容易摔跤在中间。面包做一些有趣的事情。 蛋糕混合料通常会表明你应该添加额外的勺面粉加入混合,如果你是在高海拔超过5-6000呎。你可能需要补偿甚至更多,如果你是比那更高一些。 编号：桂林电子科技大学信息科技学院 毕业设计(论文)外文翻译 （译文） 系（部）：机电工程系 专业：机械设计制造及自动化 学生姓名：李汉显 学号：1153100506 指导教师单位：桂林航天工业学院 姓名：陈志 职称：讲师 2015年5 月28日 无损检测技术在检测石油管道时的可靠性 卡瓦略·库切答（a）；雷贝洛（b）；米纳拉辛苏扎·苏哲（b）； 湖奈保尔·苏格瑞勒（c）；萨拉?迪基·苏亚雷斯（d） a、华盛顿苏亚雷斯马路大学科学技术中心，1321；巴西福塔雷萨行政长官,埃德森奎罗兹临时选举委员会:60,811 - 905 b、巴西里约热内卢联邦大学临时选举委员会:21941 - 972 c、巴西里约热内卢联邦大学土木工程系 d、巴西里约热内卢大学城临时选举委员会:21949 - 900 文章内容 文章背景：2006年11月9日收到 2008年5月21日修改后的表格 2008年5月27日认可 关键词：无损检测；可靠性；超声检测；X线摄影 摘要 这项工作的目的是评估无损检测技术（NDT）在检查石油工业中的管道焊缝的可靠性。X射线，手动和全自动的超声波都利用了脉冲回波和光线干涉原理。三个层面的缺陷分析为：缺乏渗透（LP），缺乏融合（LF）和削弱（UC）。这些测试是对含焊缝缺陷已被人为地确定为标本的管道进行测试。结果表明：全自动超声波检测缺陷与手动超声波、X光测试相比更具有优越性。此外，人工神经网络已被用于探测缺陷和缺陷的自动分类。 1简介 在长距离的流体（包括石油和天然气）传输过程中，管道运输时最安全最经济的方法。由于这一点和管道的效率，他们已用了几十年。但是由于种种因素，如腐蚀，疲劳，甚至侵蚀所增加泄漏的危险，甚至破裂，这些都是现在应该考虑的关键问题。还应该指出，许多管道铺设在接近道路，铁路，水路甚至在城市或在其下方。因此，必须有方法监测，评价和肯定管道的完整性，减少泄漏的风险，从而避免环境破坏和人群危害。多年来，无损检测在石油管道的状态检测中显示了其高效性。 无损检测技术正被研究的越来越深，同时已经作为评估工程结构、工程系统使用寿命的方法。这项研究特别注意了石油工业可能发生的设备故障导致严重后果，比如环境污染和人员伤亡。然而，一般认为应考虑采取最适当的参数来选择无损技术，剩下的就是它的使用可靠性，其中一个检测与确定缺陷大小的评估检测概率曲线（POD）是最具代表性的。 对于管道检测的两种技术超声波和X线检查比传统方法更具有出色的效率和易于 Highway Subgrade Construction in Expansive Soil Areas Jian-Long Zheng1 Rui Zhang2 and He-Ping Yang3 1 Professor and President, ChangSha Univ. of Science and Technology, Chiling Road 45, Changsha, Hunan 410076, China. E-mail: zjl_csust@https://www.doczj.com/doc/d613446203.html, 2 Ph.D. Candidate and Lecturer, School of Highway Engineering, ChangSha Univ. of Science and Technology, Chiling Road 45, Changsha, Hunan 410076, China. E-mail: zr_csust@https://www.doczj.com/doc/d613446203.html, 3Professor, School of Highway Engineering, ChangSha Univ. of Science and Technology, Chiling Road 45, Changsha, Hunan 410076, China. E-mail: cscuyang@https://www.doczj.com/doc/d613446203.html, (Accepted 22 May 2007) Introduction Expansive soil is predominantly clay soil that undergoes appreciable volume and strength changes following a change in moisture content. These volume changes can cause extensive damage to the geotechnical infrastructure, and the damage is often repeatable and latent in the long term (Liao 19848). China is one of the countries with a wide distribution of expansive soils. They are found in more than 20 provinces and regions, nearly 600,000?km2in extent. It has been estimated that the planned highways totaling 3,300?km in length pass through expansive soils areas (Zheng and Yang 200422). Improper highway construction in such areas could well lead to great losses and damage to the environment. In 2002, the Chinese Ministry of Communications (CMOC) sponsored a research project, “A Complete Package for Highway Construction in Expansive Soil Areas,” whose primary objective was to solve expansive soil problems in highway engineering. A research group with personnel from Changsha University of Science and Technology (CUST) was set up. Comprehensive laboratory tests, field investigations, and analyses were carried out, aimed at solving highway engineering problems in several different expansive soil areas. A complete presentation of the results of this research is beyond the scope of this paper, but the research on subgrade毕业设计外文翻译资料
软件开发概念和设计方法大学毕业论文外文文献翻译及原文
毕业设计外文翻译附原文
毕业设计外文翻译
本科毕业设计方案外文翻译范本
毕业设计外文翻译原文.
毕业设计外文翻译格式实例.
本科毕业设计外文翻译
毕业设计外文资料翻译译文
毕业设计外文翻译
模具毕业设计外文翻译
毕业设计(论文)外文资料翻译〔含原文〕
毕业设计外文翻译
毕业设计(论文)外文翻译(译文)
毕业设计英文翻译原文
相关主题
文本预览