Net开发平台.docx
《Net开发平台.docx》由会员分享，可在线阅读，更多相关《Net开发平台.docx（61页珍藏版）》请在冰豆网上搜索。
Net开发平台
.Net开发平台
.Net开发平台的发布标志着近十年来微软开发平台第一个重大的转变。
这个开发平台包括一个用于加载和运行应用程序的新的软件基础结构（.NETFramework和ASP.NET），一个新的开发环境（VisualStudio.NET），以及支持该结构的编程语言。
微软希望随着这个新平台的发布，评论不再将这个平台作为朦胧的软件，而且开发者也
将发现该平台使得Windows上Web应用程序（尤其是WebService）的开发更为容易。
这样或许会使更多的开发者拥护公司的操作系统和服务器产品，并将他们从与Java平台的竞争中吸引过来。
微软的客户可以将该平台用作应用程序的更可靠、更安全和更统一的标准，而微软的合
伙伙伴则可以通过帮助为该平台创建早期的胜利来加强与公司的联系。
不过，无论是客户还
是合伙厂商都应该意识到，新的平台要求他们从根本上掌握新的应用程序编程接口和编程语
言，而且它能将他们锁定在微软的操作系统和服务器产品上。
内容
简介：
微软为什么需要一个新的开发平台
机会与风险
WebServices：
是什么和为什么
.NE
TFrameworkCore
CLR捕捉
Bug，使编程更轻松
类库统一
WindowsAPI
支持
WebServices
使平台一致
ECMA标准和
WindowsLock-In
.NET开发平台工具
.NET开发平台语言
选择.NET语言的经验规则
.NET开发平台与
J2EE的比较
VisualStudio.NET
ASP.NET
ASP.NET在哪些方面补充了.NET开发平台
ASP.NET的益处
向ASP.NET进发
益处评价
软件可获得性
资源
简介
微软发布了.NET开发平台，这是自1993年7月随着WindowsNT3.0出现的Win32API后微软软件开发平台的第一次大升级。
比起Win16来，Win32提供了更多功能强大的API，
但没有对工具和技术进行引人注目的改变。
与之不同的是，.NET开发平台在开发者用以创
造应用程序的工具和技术上做了根本的改变。
.NET开发平台使得开发者创建运行在InternetInformationServer（IIS）（互联网信息服务
器）Web服务器上的Web应用程序更为容易，它也使创建稳定、可靠而又安全的
Windows桌面应用程序更为容易。
.NET开发平台包括以下内容：
·.NETFramework（架构），包括：
CommonLanguageRuntime（CLR）（通用语言运行
环境），这是用于运行和加载应用程序的软件组件；新的类库，分级组织了开发者可以在他们的应用程序中用来显示图形用户界面、访问数据库和文件以及在Web上通信的代码集。
·.NET开发者工具，包括：
VisualStudio.NETIntegratedDevelopmentEnvironment（IDE）（VisualStudio.NET集成开发环境），用来开发和测试应用程序；
.NET编程语言（例如VisualBasic.NET和新的VisualC#），用来创建运行在CLR下并且使用类库的应用程序。
·ASP.NET，一个取代以前的ActiveServerPages（ASP）的特殊类库，用来创建动态
的Web内容和Web服务器应用程序，这些都将采用诸如HTML、XML和SimpleObjectAccessProtocol（SOAP）（简单对象访问协议）等Internet协议和数据格式。
（有关该平台组件的概貌，请参看“.NET开发平台”示意图。
）
微软为什么需要一个新的开发平台。
微软希望能够藉此平台保留住它庞大的Windows开发用户的基础，否则由于Java向开
发者所做的硬件与操作系统（OSs）无关性的承诺，这些用户群可能会转向其它的平台。
开发者本身不会给微软（或任何其他针对此事的公司）带来很多收益。
不过，Windows程序员是公司内对微软产品（例如Windows本身）的极大的支持力量，而商用软件的开发者形成了向客户发售微软产品的重要渠道。
如果微软可以让开发者在新的.NET开发平台下写应用程序的话，那么就会有更多的公司购买WindowsServer和.NETEnterpriseServer（.NET企业服务器），包括SQLSever、Exchange、SharePoint、CommerceServer以及
BizTalk等。
微软尤其推重.NET开发平台用于开发一种新型的应用程序：
WebServices,或者和Web上其他应用程序交换XML格式数据的服务器应用程序。
（有关WebServices的概貌，请参看“WebServices：
是什么与为什么”。
）微软认为WebServices（为此公司已注册了名为“XMLWebServices”的商标）是公司将现有的、孤立的应用程序集成到更大的商务（以及B2B）系统中的一种成本低而效用高的方法。
微软希望
WebServices成为吸引程序员在新的平台和产品上开发的“必有”的应用程序类型，正如带有图形用户界面的桌面应用程序吸引程序员在早期版本的Windows上进行开发那样。
微软本身也计划使用该平台开发它自己的公共WebServices（称作.NETMyServices），它将给Internet上的客户提供数据存储以及其他的功能。
（有关微软关于自己商务的长期计划以及该计划中.NET开发平台、WebServices和.NETMyServices的作用的概貌，请参看2001年7月的研究报告“Understanding.NET”（“理解.NET”。
）
.NET开发平台
.NET开发平台是一组用于建立Web服务器应用程序和Windows桌面应用程序的软件组
件，用该平台创建的应用程序在CommonLanguageRuntime（CLR）（通用语言运行环境）
（底层）的控制下运行。
CLR是一个软件引擎，用来加载应用程序，确认它们可以没有错
误地执行，进行相应的安全许可验证，执行应用程序，然后在运行完成后将它们清除。
类库
集提供了使应用程序可以读写XML数据、在Internet上通信、访问数据库等的代码。
所有
的类库都建立在一个基础的类库之上，它提供管理使用最为频繁的数据类型（例如数值或文
本字符串）的功能，以及诸如文件输入/输出等底层功能。
Web服务器应用程序通常依赖于ASP.NET，一个处理Web请求的服务器端的库。
ASP.NET又依赖一个用于发送和接收SOAP信息的WebServices库，以及一个用于以浏览
器接收用户输入并动态地生成Web页面以示响应的Web用户接口（UI）（有时称作Web表
单）。
Windows桌面应用程序通过使用Win表单库（也称作Windows表单）可以显示一个
图形UI。
最后，VisualStudio.NET提供了一个用于在该平台上创建应用程序的图形Integrated
DevelopmentEwironment（IDE）（集成开发环境）。
程序员可以使用一种或多种.NET编程语
言，来编写他们的代码，例如微软自己的VisualBasic.NET（VB.NET），VisualC++,VisualC#
和JScrjpt.NET等。
大量其它的.NET编程语言可以从第三方厂商获得。
.NET开发平台是一组用于建立Web服务器应用程序和Windows桌面应用程序的软件组
件，用该平台创建的应用程序在CommonLanguageRuntime（CLR）（通用语言运行环境）
（底层）的控制下运行。
CLR是一个软件引擎，用来加载应用程序，确认它们可以没有错
误地执行，进行相应的安全许可验证，执行应用程序，然后在运行完成后将它们清除。
类库
集提供了使应用程序可以读写XML数据、在Internet上通信、访问数据库等的代码。
所有
的类库都建立在一个基础的类库之上，它提供管理使用最为频繁的数据类型（例如数值或文
本字符串）的功能，以及诸如文件输入/输出等底层功能。
Web服务器应用程序通常依赖于ASP.NET，一个处理Web请求的服务器端的库。
ASP.NET又依赖一个用于发送和接收SOAP信息的WebServices库，以及一个用于以浏览
器接收用户输入并动态地生成Web页面以示响应的Web用户接口（UI）（有时称作Web表
单）。
Windows桌面应用程序通过使用Win表单库（也称作Windows表单）可以显示一个
图形UI。
最后，VisualStudio.NET提供了一个用于在该平台上创建应用程序的图形Integrated
DevelopmentEwironment（IDE）（集成开发环境）。
程序员可以使用一种或多种.NET编程语
言，来编写他们的代码，例如微软自己的VisualBasic.NET（VB.NET），VisualC++,VisualC#
和JScrjpt.NET等。
大量其它的.NET编程语言可以从第三方厂商获得。
机会与风险
新的.NET开发平台给合伙厂商和客户带来了新的机会与风险。
对于合伙厂商而言，新的平台意味着建立或加强与微软之间的关系的一次机会。
微软需
要早期的胜利来为该平台提供动力，那些能够提供这样的机会的合伙厂商就有可能建立和培
育与微软间的坚实的共进关系。
例如，M将开始使用各种.NET技术（例如VisualStudis.NET和.NETFramwork等）来发送它的四种重要的WebServices：
JobseekerNotification（求职者公告），JobPosting（职位公布），JobSearching（职位搜索），以及ResumePosting（简历公布）。
这优点类似于Visio的方法，它采用对象链接与嵌入和COM技术建立了与微软的伙伴关系，并且最终被微软购并。
不过，新的平台对于现在的合伙厂商也是一种风险，因为它将重新布置游戏领域，迫使
先前与之关系紧密的或从中受惠的合伙厂商在新平台上重新起步，这样就给了其他公司加入
的机会。
更为重要的是，该平台建立的合作方机会根据价格分配，因为微软将为那些全盘采
纳它的平台而摒弃其他公司产品的合作方保持最大的回报。
Visio确立了完全使用
Windows
3的目标，这使它可能已经丧失了与其他厂商建立关系，以便将它的产品卖给喜欢其他的
OS的客户的机会。
新的平台将使公司的IT部门受益，它使程序员可以在短时间内即可创建更为安全可靠、
扩展性更强的应用程序。
不过实际上，这要等到.NETFramework可以使用以后，目前
IT部门还必须将Framework分配到多个桌面上，因为微软还没有将Framework加载到它任何一个操作系统上，包括最近的WindowsXP。
.NET开发平台实际上不会改变低层代码的开发（例如设备驱动程序，定位多个
OS（操作系统）的应用程序，或者用于PC或游戏机的游戏程序），所以它对商用软件程序员的影响有限。
不过，它将为Windows应用程序，基于Web的应用程序以及
WebServices（对于公司程序员而言这是一个分水岭般的事件），提供一个单一、细致的设计平台。
对于公司来说，面临的风险就是.NET开发平台将把它们锁定WindowsOS和.NETEnterpriseServers（.NET企业服务器）上。
这篇报告深入讨论了.NET开发平台，并且讨论了其关键组件，包括：
拥有自己的
CLR和类库的.NETFramework，新的工具和语言，以及ASP.NET等。
报告还分析了.NET平台可能产生的问题与提供的好处。
WebServices：
是什么与为什么
WebServices是一个软件组件，它通过将消息以XML格式进行编码，并将消息通过标
准的Internet协议（例如HypertextTransferProrocol（HTTP）（超文本传输协议））发送出去
来与其它的应用程序进行通信。
一个WebServices类似于这样一个Web站点：
没有用户接
口，向应用程序而非用户提供服务。
WebServices不从浏览器获得请求并返回相应的Web页面，而是从应用程序接收XML格式的请求消息，执行任务，然后向应用程序返回XML格式的响应消息。
IBM和微软一致提倡将SOAP作为一种用于Webservices的消息标准。
一条
SOAP消息如同一封信，由一个基于XML格式的“信封”和载有消息数据的“正文”两部分组成，“信封”部分包含一个指明消息接收者地址的头部和一系列投递选项（例如加密信息）。
（微软喜欢将此编程模型称作“XMLWebServices”——采用“XML”意在强调其开
放性。
——但是这个基于一套WorldWideWebConsortium（W3C）协议标准的模型，业界
习惯上简单称其为“WebServices”。
）
微软和IBM等其他供应商提倡将WebServices作为用于Internet上的互连应用程序通信
的程序设计模型。
这些公司相信通过Internet相互连接的应用程序，将增强与它们的合作供
应商和客户协同工作的商务能力。
通过在一个现有的公司应用程序的顶层创建一个Web
Services层，各个组织可以允许外部系统通过
Internet（或企业Intranet）调用应用程序的功能，但却不必修改应用程序本身。
例如，有几家公司正在创建WebServices，来充当驻留在主机内的订单一入口应用程序的前端，这允许客户的订货系统通过Internet提交订单。
作为公司内整合由各个部门独立开发的应用程序，以降低伴随公司合并与购并而来的IT整合费用的方法，将WebServices放在现有应用程序的顶层相当重要。
微软也希望使用WebServices进入服务供应商领域，通过Internet向付费客户提供必要
的服务。
计划中的服务首要的是.NETMyServices，一套由微软管理的数据存储
WebServices，包括由单个用户输入的个人信息，例如信用卡号和日历安排。
桌面和
Web服务器应用程序，如果获得了用户的许可，将通过WebServices协议从那些
Internet上的数据库中取回信息。
.NETFramework核心
所有在.NET开发平台上创建的应用程序运行都需要运行两个核心块：
CommonLanguageRuntime（CLR）（通用语言运行环境），这是一个软件引擎，用来加
载应用程序，确认它们可以没有错误地运行，进行相应的安全许可验证，执行应用程序，然
后在完成后将它们清除。
.NETFramework类库，向程序员提供所需用来编写在CLR的控制下运行的代码的软件
组件。
它们按照单一有序的分级组织提供了一个庞大的功能集——从文件系统到对XML功
能的网络访问的每一样功能。
Web服务器应用程序也可以使用ASP.NET，这个类库将在做详细解释。
桌面应用程序
不需要ASP.NET。
CLR描述Bug，使编程更轻松
CLR有两个主要的目标：
·提高应用程序的稳定性和安全性
·减少应用程序开发者所必须写的冗长而又易出错的底层代码的容量
这两个目标类似于诸如Sun和IBM等厂商试图用Unix和主机上的Java平台去解决的问
题。
为了解决Windows上的这些问题，CLR对加载和执行应用程序的编程模型做了根本的改
变。
CLR如何工作
一个应用程序是作为称作汇编的文件或文件集进入CLR的。
这个汇编包是MicrosoftIntermediateLanguagl（MSIL）代码，CLR将其翻译成可执行的本机代码。
由于可以对从MSIL到本机代码的应用程序翻译的控制，使得CLR可以管理应用程序的执行并且防止各种
问题的发生，因此也就有了术语可控制代码。
除了MSIL代码，汇编还包含有详细描述了MSIL代码正确执行所需的各种相关数据类型
的元数据。
最后，汇编还包括一个清单——一个列出了汇编中所有文件和软件组件的文档，
该文档还指出CLR在哪里可以找到具有应用程序运行所需组件的其它汇编。
为了加载一个应用程序，CLR使用汇编的清单来确定应用程序所需的汇编的正确版本。
然后CLR检查应用程序的全部汇编——即，MSIL代码本身与描述它的元数据——从而确认
代码是“类型安全”的，这表明它只执行对恰当数据类型的恰当的操作（也就是说，它不会
允许开发者使用一个整数作为一个函数指针），而且它只访问经过授权可以访问的内存位置。
接下来CLR加载应用程序的汇编中的MSIL，并且在此过程中，收集有关汇编的“证据”，
例如：
·它是从哪里下载或安装的
·它需要执行什么功能（也就是说，它是否需要写文件或发E-mail）
·什么用户试图运行它
·汇编是否拥有来自信任的开发者的数字签名，以及进行数字签名后汇编是否有改动。
执行控制代码
CommonLanguageRuntime（CLR）（通用语言运行环境）组件（以灰色显示）加载并运
行应用程序。
（1）ClassLoader（类加载器）将应用程序的汇编加载到内存中。
汇编包括Microsoft
IntermediateLanguage[MSIL]代码、描述应用程序的汇编中的软件组件的元数据，以及其
他应用程序所需的组件。
接下来，ClassLoader使用应用程序汇编的元数据，试图加载任何应用程序所需的组
件的支持汇编。
例如，它可能加载包含一个桌面应用程序所需的图形用户接口（GUI）控制
5
的汇编。
ClassLoader使用VersioningPolily（版本政策）（由应用程序的开发者或者系
统管理员指定）采确定加载它所支持的哪些版本汇编。
例如，一个VersioningPolicy可能
要求只能使用特定版本的GUI组件，即使有更多最近的版本可以利用。
这消除了组件版本问
题，这样的问题在过去十分普遍地存在于Windows应用程序中。
（2）一旦应用程序和受支持的汇编加载后，Verifier就得检查它的内容以确保它是类
型安全的（type-safe），并且确定对于应用程序适当的安全许可。
这是加强安全过程的第一
步。
（3）本机编译器将MSIL转换为可控制的本机代码，这是处理器相关代码，它知道如何
与CLR提供的服务，例如碎片整理（声明内存不再为应用程序所用）或CLR安全系统（将增
强应用程序的安全许可），进行行交互。
这些证据构成了.NETFramework中的安全要素，使得CLR可以判断是否运行应用程序，
以及运行时需要具有什么许可。
接下来，CLR将MSIL代码翻译成处理器可以执行的本机代码。
（微软将此称为“可控
制的本机代码”，以与“不可控制的本机代码”相区分，后者是用C++这样较老的语言写的，
CLR对其没有控制。
）一项称为Just-in-Time（JIT）编译的能力使得CLR能将翻译过程延迟
至真正需要它时，这样就使CLR避免翻译不常用的代码。
（关于这个过程的图解说明，请参
看“执行可控制代码”示意图。
）
最后，CLR监控着翻译代码的运行，并且定期清空应用程序释放的内存（使用一个称
作“碎片整理”的进程）。
CLR的好处
CLR通过下列方法增强了应用程序的可靠性：
它减少了不同版本组件间的冲突。
CLR可以帮助避免在一台机器上安装相冲突的软件
组件时发生的问题——现在的Windows应用程序如果试图加载不正确版本组件时可能失败。
当CRL加载一个应用程序时，它使用元数据和汇编清单来确保它加载了所有组件的正确版
本。
例如如果应用程序需要访问数据库，CLR就使用清单中的信息来寻找并加载版本正确
6
的数据访问组件。
系统也允许并列安装多个版本的组件。
它减少了由于通常的编程错误所带来的
bug和安全漏洞的数量。
CLR监控代码以确保
它不会有通常的编程错误，这些错误可能导致程序执行不正确的功能，例如试图使用一个整
数作为函数指针，强行将数值型数据存放到分配给文本数据的位置，或者是载入数据时覆盖
代码（由于缓冲溢出）。
减少来自这些通常的编程错误的
bug意味着应用程序不但运行得更
可靠，而且攻击者有机可乘的漏洞和弱点也更少。
增强的安全性能使恶性代码的运行更为困难。
因为
CLR可以理解每个应用程序的代码
的身份和来源，所以它可以决定应用程序是否被允许执行特定的任务（例如读写本地存储器
或者发送
E-mail）。
这给现在的安全模型增加了另外一层保护，在现在的安全模型中应用程
序在运行它的用户帐号的安全背景下运行（例如，管理员机器上所有的应用程序都用管理员
级的许可在运行）。
内存泄漏更少。
如果内存和组件分配给一个应用程序使用，但却得不到释放，这样就会
导致系统超出内存运行，要么会冲击系统，要么就需重新启动、释放内存。
CLR的内存管
理和碎片整理可大大降低这种问题发生的可能性。
组装函数（Plumbingfunctions）减少了
bug，同时也节约了开发者的时间。
最后，
CLR
提供了许多与内存和对象管理、数据编组，以及线程（
thread）相关的低级的，或组装函数。
这不仅通过降低
bug的发生可能性而建立了更好的可靠度，而且还使得程序员能将精力集中
于用于他们特定的应用程序的“行业”代码上，而不必重新实现标准的
Windows函数。
从
Windows的过渡
最后，CLR执行的一项非常重要的功能是在可控制代码和不可控制代码（即脱离
CLR
运行的传统的
Windows代码）间起中介作用。
特别地，它使开发者可以将新的
.NET代码与
现存的
Windows库和
COM组件结合起来，并将一个应用程序逐渐地从老平台迁移到新平
台上来。
（请参看“混合可控制代码与不可控制代码”示意图）。
不过，需要指出的是，不可控制代码脱离
CLR的控制而运行，因此有可能冲击应用程
序，泄露内存，或者通过缓冲溢出打开安全漏洞。
一个.NET应用程序只是和它的最弱环节
——它的不可控制代码一样强壮。
类库统一
WindowsAPI
.NETFramework类库提供了几乎所有应用程序都需要的公共代码。
和在
Windows和它
的
SDK中发送的代码库一样，类库使得开发者能将精力集中于编写他们的应用程序所独有
的代码，而不必一再重复编写类似读写文件这样经常使用的功能的代码。
类库还解决了当前的
Windows代码库中存在的一个问题：
当微软将向
Windows绑缚新
功能时，API和
SDK之间就会出现混乱。
（各种“版本”中的
Java库试图解决非
WindowsOS
上类似的、甚或更严重的问题，即：
来自各种不同的厂商，用于诸如文件输入
/输出和消息
收发等基本功能的使人困惑的
API。
）
类库做什么
所有的可控制代码都组织在称为类的（这就是类库的来源）逻辑组中，这些类按照称作
域名空间的分级制度排列。
.NETFramenork类库在域名空间
升级会员 