Microsoft .NET 简介

引言

微软与 Sun 的对抗

它很新，它很强大，它解决了许多问题，它威胁到了庞大的 Java 信徒群体，最棒（或最糟）的是，它来自微软。您猜对了，我说的就是 .NET。 

大约在 1995 年，Java 引起了与今天 .NET 相同的轰动。也许我有点不公平；实际上，Sun 的 Java 比 .NET 更具影响力。我无意贬低 .NET 的出现；但事实就是事实！Sun 的 Java 引入了一种革命性的软件开发方法。以前，开发人员专注于 Visual C++、VB 或 Tcl/Tk（针对 UNIX 平台）。找到一个精通多种竞争语言的人几乎是不可能的。有了 Sun 的 Java，程序员只需要了解一种语言——Java；因此，Java 为程序员提供了一种独特的工具，解决了他们长期以来存在的平台独立性问题。 

Sun 通过 Applet、JSP（Java 服务器页面）和 Servlet 解决了 Web 开发问题，进一步服务于计算机行业。然后是 Sun 的 EJB（企业 Java Bean）。EJB 结束了痛苦的分布式应用程序开发时代。所有这些时候，当 Sun 赢得我们的赞赏时；微软正竭尽全力与之匹敌。尽管 J2EE 使用的许多技术是由微软引入的（例如，OLE/COM 早于 EJB，ASP 早于 JSP 等），但 Sun 的 J2EE 改进了其中许多技术，并通过其 Java 平台独立方法（对于 .NET，微软也做了同样的事情——即不仅改进了现有技术，还改进了 J2EE）将它们推广开来。 

但 Sun 是无与伦比的。Sun“免费分发”的独特方法帮助他们在开发者中获得了人气。Sun 通过开发或增强 JSP、Servlet、EJB、JMS、JNDI、JNI 等工具来满足行业需求。Sun 将这些优秀的工具整合到一个大伞下——Java2 企业版（J2EE）。微软的 J2EE 对等物是微软的 Windows **DNA** 编程模型。DNA 的流行受到了微软专有方法的影响；而 J2EE 是一系列规范，DNA 则是微软的专有实现。随着世界越来越依赖互联网——以及 Sun 的工具成为 Web 应用程序的首选媒体，微软似乎正在输掉这场战斗。但微软有一个辉煌的历史，即晚启动但迅速赶上（Windows vs. Macintosh，Internet Explorer vs. Netscape）。因此，微软派出了他们最优秀的人才，并将该项目命名为下一代 Windows 服务（**NGWS**）。该项目的成果就是我们现在所知的 .NET。 .NET 借鉴了 Sun 的 J2EE 的许多思想；但这一次，微软确实超越了自己。 .NET 加强了 J2EE 的许多功能，并弥补了微软的大部分失误。 

几个月前，当 .Net（和 C#）的炒作开始时，我拒绝了这种炒作，因为我更喜欢 Java 和 Visual C++。在 Web 开发或分布式应用程序开发方面，我更喜欢 Sun 的 Java、Servlet、JSP 和 EJB。而在 Windows 应用程序方面，微软的 Visual C++ 是我的首选工具。所以我的第一反应是——“嗯，又一个微软的花招；我绝对不会上当！！！”。但后来我开始阅读相关资料，读得越多，越喜欢。仿佛是微软历史上第一次真正听到了我们的呼声。有了 .Net，微软不是在告诉我们如何做我们的工作，而是经过对开发者反馈的彻底考量后得出的成果。

用 Visual C++ 编程总是让我感到自豪。那些使用 Visual C++ 开发 OLE、COM、COM+、ActiveX 应用程序的人会明白我的意思。每次我制作一个 ActiveX 客户端/服务器或 ActiveX 控件，我都会带着满足感和成就感离开电脑。但制作一个 Java Bean 从来没有给我带来那种满足感——因为它太简单了！！！。有了 .NET，微软让许多事情变得更加简单，不仅与他们之前的技术相比，甚至与 Java 相比也是如此。

当我开始阅读 .NET 时，我几乎总是遇到偏颇或单方面的观点。所以，与其被微软或 Sun 的说法左右，我决定自己形成观点——这也是写这篇文章的主要原因。

本文的其余部分将深入探讨 .NET。文章最后将总结 IT 专家们对未来的预测。

• .NET - 一个框架          
• .NET 的主要组成部分 
• 什么是“通用语言规范”（CLS）？  
• 什么是“通用语言运行时”（CLR）？
• 什么是“Microsoft 中间语言”（“MSIL”或简称“IL”）？
• 什么是“通用类型系统”（CTS）？  
• .NET Framework 基类  
• 什么是 Web 服务、 Web 窗体、 Windows 窗体？
• 各种 .NET 语言 - VB.Net、ASP. NET、C#、J#、VC.NET
• 未来为我们准备了什么？

.NET - 一个框架 

最重要的问题是：什么是 .NET？最简单的答案是：**它是一个可以开发和运行 Windows 应用程序的框架**。我承认这个答案并没有说明太多。为了理解 .NET，我们必须回顾过去，追溯 Windows 的发展和 Windows 编程的出现。 

让我们看看传统的 Windows 应用程序是如何工作的。 

Windows 为程序员提供了各种函数——称为 API。从 Windows 首次进入商业市场到最新的 Windows XP 版本，API 都是让 Windows 知道你想让它做什么的基本工具。如果你想创建一个对话框，你必须调用 Windows 提供给你的特定 API。创建一个按钮需要另一个 API 调用。清单不断增加。随着新的 GUI 的出现，Windows 中引入了新的 API。但使用这些本地 API 是一项非常艰巨的任务。创建一个简单的窗口来打印“Hello World”可能需要一百多行。与 DOS 中 5 行的“Hello World”程序相比。由于这种困难，Windows 编程被认为是专家的事情。微软和其他商业组织认识到这一点，并开始营销使程序员生活更轻松的 Visual 工具。使用 Visual C++、Visual Basic、Borland C++ 和其他类似的 IDE，制作 Windows 程序变得更加简单。 

各种供应商开发了自己的“包装类”，以面向对象的方式封装了 Windows API。Visual C++ 中使用的 Microsoft Foundation Classes (MFC) 就是包装类的一个例子。Visual Basic 的 MFC 等效项是 VBRun；对于 Visual J++，它是 WFC。这些包装类与 Visual GUI 工具一起，使得创建 Windows 程序非常方便。 

微软认识到应用程序需要一种可靠的方式来相互通信。这导致了对象链接和嵌入 (OLE) 的引入。OLE 是一个非常有用的概念，但它有两个主要缺点：编程难度极大，并且其范围非常有限——即它只做一些事情，如拖放、剪贴板共享、OLE 客户端、OLE 服务器等。微软解决了（或至少试图解决）这两个问题。他们将 OLE 升级为 COM。COM 比 OLE 功能更强大，并引入了像 ActiveX 控件这样的新概念，直接与 Java Applet 竞争。至于 OLE/COM 的编程难度；微软扩展了 MFC 和 VBRun 来处理大部分繁琐的工作。尽管在 Visual C++ 中制作 ActiveX 应用程序仍然有点棘手，但在 Visual Basic 中开发 ActiveX 应用程序却极其简单；因此，Visual Basic 成为首选的 ActiveX 开发媒体。

互联网革命带来了新的问题和挑战。C/C++，曾是冠军的工具，不适合/未准备好进行 Web 开发。微软试图扩展 MFC，并包含了一些面向网络的类——如 CSocket、CASyncSocket，以及一些基于 HTTP 的类。使用这些类，程序员可以开发分布式应用程序——尽管需要付出相当大的努力。但这些应用程序总是定制的，并且针对特定任务。开发人员必须自己处理棘手的网络通信细节。到目前为止，面向对象分析和开发已开始普及。尽管远程过程调用 (RPC) 等技术对程序员大有帮助；但其范围有限。随着程序员遵循面向对象开发，RPC 并没有多大帮助；因为 RPC 不允许将对象作为参数传递。这个问题通过引入行业公认的标准，如 CORBA、IIOP、RMI、DCOM 等得到了解决。所有这些标准都使用定制的协议在网络上传输对象，并且它们要求服务器和客户端之间紧密耦合——即客户端需要完全了解如何与服务器通信。由于这种紧密的客户端-服务器耦合，所有这些协议都需要大量的部署工作，才能使分布式应用程序正常运行。Sun 提出了 RMI 之上的另一个层——著名的企业 Java Bean (EJB)。EJB 容器免费提供了大量服务——程序员所要做的就是继承（继承）适当的 EJB 基类，然后就可以得到一个功能齐全的分布式应用程序。EJB 使程序员的生活变得极其简单；但它并没有消除客户端-服务器耦合问题。 

与此同时——微软并没有看到危机——**微软需要一些根本性的新东西来适应不断变化的时代表现出和不断变化的需求。**微软很快意识到升级现有技术将不起作用——他们需要的是对其理念的彻底改变。OLE 被升级为 COM——并受到所有人的欢迎。COM 随后升级为 COM+。微软通过引入 DCOM 来解决分布式编程问题。尽管 COM/COM+/DCOM 都是很好的技术，但这些技术需要大量的学习曲线。另一方面，Sun 正在使事情变得更容易，因此大多数开发人员都转向基于 Java 的技术来开发分布式企业应用程序。

微软——在经历 DNA 的冷遇后——召集了他们的专家，让他们反思 DNA 并提出未来的愿景。这个小组提出了许多新的、伟大的想法，让微软意识到，无论是在 MFC/VBRun/WFC、COM/COM+/DCOM、ASP、API 等方面进行多少升级或扩展，都无法实现这一新愿景。因此，他们做出了一个激进但正确的决定——这个决定是推出一个重大、新颖、能够弥补微软失误的东西——这就是 **.NET Framework**。 

本文的其余部分将讨论 .NET 框架的一些主要特性和组件。在简要介绍 .NET 后，我将通过回答“什么是 .NET？”这个价值百万美元的问题来结束本文。 

本文假定读者具有扎实的编程经验。它还假定具备一定的 JAVA 经验。虽然不需要 RMI、EJB、ActiveX、VC、VB 的经验，但对这些工具的初步了解将有助于更好地欣赏 .NET。 

返回顶部 

.NET 的主要组成部分 

下图描述了 .NET Framework 的各种组件[3]

现在我们简要解释这些组件……

.NET 框架只能被符合 .NET 的语言所利用。微软的大部分语言都已完全符合 .NET。

.NET 还引入了 Web 窗体、Web 服务和 Windows 窗体。它们被单独显示而不是作为特定语言的一部分，是因为这些技术可以被任何 .NET 兼容语言使用。例如，Windows 窗体被 VC、VB.NET、C# 等用于提供 GUI。

.NET 的下一个组件是 .NET Framework 基类。这些是通用的类库（类似于 Java 包），可以被任何 .NET 兼容语言使用。这些类为程序员提供了高度的功能，他们可以在程序中使用。例如，有处理读取、写入和操作 XML 文档的类，增强的 ADO 等。

最底层是 CLR——通用运行时语言。CLR 在 [7] 中有详细讨论。 

返回顶部 

什么是“通用语言规范”（CLS）？

.NET 的一个明显主题是各种编程语言之间的统一和互操作性。为了实现这一点；必须制定某些规则，并且所有语言都必须遵守这些规则。换句话说，我们不能让语言随意创建自己的扩展和自己的花哨新数据类型。CLS 是规则和约束的集合，每种语言（希望实现 .NET 兼容性）都必须遵守。微软定义了三个级别的 CLS 兼容性/合规性。每个合规性级别的目标和目的已放在一边。下面是三个合规性级别及其简要描述。

兼容生产者

在此类语言中开发的组件可以被任何其他语言使用。

消费者

此类别中的语言可以从其他语言生成的类。简单来说，这意味着该语言可以实例化用其他语言开发的类。这类似于您的 ASP 代码如何实例化 COM 组件。 

扩展器

此类别中的语言不仅可以像 CONSUMER 类别那样使用类；还可以通过继承来扩展类。

随 Microsoft Visual Studio 一起提供的语言，如 Visual C++、Visual Basic 和 C#；都满足以上三个类别。供应商可以为他们的语言选择以上任何一个类别作为目标合规性级别。

返回顶部 

什么是“通用语言运行时”（CLR）？

CLR 是 Java 虚拟机 (JVM) 的 .NET 对等体。它是将 MSIL 代码转换为宿主机器语言代码的运行时，然后将其适当地执行。[7] 提供了 CLR 的详细描述。 

返回顶部 

什么是“Microsoft 中间语言”(MSIL)？

.NET 编程语言（C#、VB.NET、J# 等）不编译成可执行代码；而是编译成一种称为 Microsoft 中间语言 (MSIL) 的中间代码。作为一个程序员，您无需担心 MSIL 的语法——因为您的源代码会自动转换为 MSIL。MSIL 的完整规范可在 http://msdn.microsoft.com/net/ecma/part_3_IL_inst_set.pdf 找到。然后，MSIL 代码被发送到 CLR（通用语言运行时），CLR 将代码转换为机器语言，然后在宿主机器上运行[7]。MSIL 类似于 Java 字节码。Java 程序由 Java 编译器编译成 Java 字节码（.class 文件），然后将该类文件发送到 JVM，JVM 进行解释并在宿主机器上运行。

返回顶部 

什么是“通用类型系统”（CTS）？

到目前为止，我们一直在谈论语言互操作性和 .NET 类框架。没有这些，所有语言共享相同的数据类型都是不可能的。这意味着 int 在 VB、VC++、C# 和所有其他 .NET 兼容语言中都应该意味着相同的事情。其他所有数据类型也是如此。这是通过引入通用类型系统 (CTS) 来实现的。CTS 就像 Java 一样，将每种数据类型定义为一个类。每种 .NET 兼容语言都必须坚持这一定义。由于 CTS 将每种数据类型定义为一个类；这意味着只有面向对象（或基于对象）的语言才能实现 .NET 兼容性。下面是 CTS 支持的数据类型列表： 

 

数据类型	描述
System.Byte	0-255 之间的 1 字节无符号整数
System.Int16	2 字节带符号整数，范围如下： 32,768 至 32,767
System.Int32	4 字节带符号整数，包含以下范围的值： -2,147,483,648   至   2,147,483,647
System.Int64	8 字节带符号整数，包含以下范围的值： -9,223,372,036,854,775,808 至 9,223,372,036,854,775,807
System.Single	4 字节浮点数。值限制为： **负值：** -3.402823E38   至 - 1.401298E-45  **正值：** 1.401298E-45 至 30402823E38
System.Double	8 字节宽浮点数。值限制为： **负值：** -1.79769313486231E308 至 - 4.964065645841247E-324 **正值：** 4.964065645841247E-324 至 1.79769313486232E308
System.Object	4 字节对象地址引用
System.Char	2 字节单个 Unicode 字符。
System.String	最多 20 亿个 Unicode 字符的字符串。
System.Decimal	12 字节带符号整数，小数点两侧可有 28 位数字。
System.Boolean	4 字节数字，包含 true(1) 或 false (0)

返回顶部 

.NET Framework 基类

让我们看一下下面的 Visual C++ 代码片段。 

CView myView;
myView.MessageBox("Hello World", ".Net Article", MB_OK);
::MessageBeep(MB_ICONHAND);

上面的代码首先创建一个 CView 对象。u 是一个内置的 MFC 类。第二行代码调用 CView 方法 MessageBox() 来显示一个包含 OK 按钮和“Hello World”消息的对话框。对话框的标题是“ .Net Article”。第三行程序直接调用一个 Windows API，“::”在方法前的作用域解析符号表示这是一个直接的 API 调用。 MessageBeep() 使用系统定义的波形文件“MB_ICONHAND”来播放相应的声音。上面的三行使用了两种不同类型的函数——一种是 MFC 提供的，另一种是操作系统提供的。请记住，MFC 只是封装了 API 的一组包装类。您可以完全绕过 MFC，仅使用 API 开发应用程序。用 Visual Basic 编写相同的代码呢？Visual Basic 的 MFC 等效项是 VBrun。尽管您可能能够  在 VB 中使用 MessageBeep() API；但 CView 类在 VBRun 中不存在。您必须学习 VBRun 才能使用 CView 的等效项。其他编程语言也是如此；为了进一步使情况复杂化，各种供应商都有自己的包装类名称和层次结构。这意味着 MFC 是微软为 C++ 提供的包装类；Borland 有自己的包装类。Java 也是如此。微软提供了一个名为 WFC 的强大包装类包，可与 Visual J++ 一起使用；其他供应商有自己的包装类。 

此外，如果您的应用程序使用 COM 组件，那么您的代码在不同语言中的外观将截然不同——这是因为不同的语言对 COM 有不同的实现，并且有不同的数据类型。下面是 COM 组件代码的摘录（摘自 SMTP.Server 应用程序）。下面的代码返回一个字符串。但在 COM 的世界里，没有字符串数据类型；取而代之的是“BSTR”。字符串在 MFC 中的实现是 CString 类（非常类似于 Java 中的 String 类）。 CString 提供了一个名为 AllocSysString() 的函数，该函数执行到 BSTR 的必要转换。 

BSTR CServer::GetCcTo() 
{
   return m_strCcTo.AllocSysString();
}

如果 COM 组件是用 VB 开发的。上面的代码需要经过重大修改。基于以上讨论，我们可以得出以下结论：

每种 Windows 应用程序语言都有自己的实现和接口，用于以下方面：

1. COM 组件，

2. 操作系统特定 API（例如，Win32API、Win16 API、Windows CE API）

3. 包装类（例如，MFC、VBRun、WFC）

上述差异给程序员带来了不必要的工作；并阻碍了各种语言之间的互操作性。 

许多 Visual C++ 程序员不愿学习 Visual Basic，尽管 VB 比 VC 容易得多。尽管 VC 应用程序速度更快，这可能是程序员偏爱 VC 的原因，但在简单的 COM 组件的情况下，VB 的生产力提高足以弥补速度上的轻微损失。我个人宁愿坚持使用 VC，主要是因为我将不得不学习 VBRun、VB 特定数据类型和 VB 特定 COM 实现。如果 VB 和 VC 拥有共同的数据类型，并且 MFC 也存在于 VB 中，那将是很好的。这将大大减少我的学习曲线，并鼓励成千上万像我一样的程序员拥抱 VB。

现有的 COM 实现还有另一个问题。虽然 COM 组件可以在许多语言中使用，无论它们是如何开发的。但不能扩展/继承这些组件。我一直很喜欢能够继承/扩展 COM 组件的想法。不幸的是，除非您能访问组件的源代码，否则（至少到目前为止）是不可能的。因此，当前需要的是：

• 通用包装类实现

• 通用数据类型系统 

• 继承/扩展 COM 组件的能力。

而这一切的解决方案是——.NET 类框架。那些熟悉 MFC/VBRun/WFC 的人可以把这个框架看作是一组包装类，这些类在 VC、VB 和任何其他 .NET 兼容语言（遵循微软制定的通用语言规范“CLS”的语言）之间共享。所以现在我们只需要学习一个类框架，无论我们是在 VB、VC 还是任何其他 CLS 兼容语言中工作，都可以使用它。与 .NET Framework 相关的一个重要术语是**命名空间**。由于您将在任何 .NET 文章中频繁遇到这个术语；最好正式定义它。**命名空间** 是相关接口、结构和类的逻辑分组。Java 程序员熟悉包的概念。命名空间非常类似于包的概念。一个命名空间可能包含进一步的命名空间。这将形成一个树状的分层结构。 .Net 类框架就是命名空间的层级结构。在 .NET 类框架中，“System”是起始命名空间。System 内的一些其他命名空间是 System.Security、 System.Data、 System.Console、 System.WinForms 等。 

如果您想编写 .NET 应用程序，您将不得不学习 .NET 类框架；就像 Java 程序员学习基本包层次结构（例如，java.util、java.lang、javax.servlet 等）一样。

返回顶部 

Web 服务 

Web 服务是 ActiveX 的扩展。那些使用过 ASP 和 JSP 的人，都知道 ASP 的明显缺点。JSP 已经丰富了 Bean 和 Tag 的概念。ASP 对应的 Bean 和 Tag 是 ActiveX 控件和 ActiveX 自动化服务器。让我花一点时间进一步解释这一点。*Web 服务不是微软的专有标准。它是 W3Consortium 标准，由微软、IBM 和许多其他行业巨头开发。*

函数有两种类型。ASP 内置函数，以及程序员定义的/实现的函数。为了使用内置函数，您只需传递适当的参数并简单调用这些函数。函数由 ASP 本身实现。字符串操作函数、数字转换函数是内置函数的例子。 

程序员定义的函数是由程序员定义和实现的函数。程序员可以在同一个 asp 文件中编写这些函数，也可以将它们编写在另一个文件中。如果函数代码驻留在同一个 asp 文件中，那么程序员可以直接调用该函数。如果函数驻留在另一个文件（例如，“func.asp”）中，那么程序员需要通过编写语句 <!-- #include file="func.asp" --> 来包含该文件；现在程序员就可以使用该函数了。程序员还可以制作 ActiveX 自动化服务器，并调用这些 ActiveX 服务器的各种函数。但有一个限制非常明显——*无论使用哪种类型的函数，函数都必须物理地驻留在同一台机器上*。例如，您的 ActiveX 自动化服务器必须实现为 .dll 或 .exe，并且在 asp 代码可以调用其函数之前必须在 Windows 注册表中注册它。（您可以下载 SMTP.Server——作者开发的 ActiveX 组件——以更好地了解如何从您的 ASP/VC/VB 代码中使用 ActiveX 组件。）在一个互联网已成为必需品，也成为一种生活方式的世界里——很明显，这个限制是一个很强的限制。微软对这个问题的答案是**“Web 服务”**。这个想法大致是这样的：

1. Web 服务提供商开发有用的函数，并发布/宣传它们。Web 服务提供商使用 Web 服务描述语言 (WSDL) 标准来描述函数接口。这很像 ActiveX 自动化服务器所需的类型库 (TLB) 和对象描述语言文件 (ODL)。

2. 需要的函数/客户端程序员通过一个称为——Web 服务发现或 SOAP 发现（也称为 Web 服务**发现**的 **DISCO**）的过程进行查找。

3. 客户端程序和 Web 服务之间的实际通信通过一种称为 简单对象访问协议 (SOAP) 的协议进行——SOAP 是一种基于 XML 的轻量级协议，用于在去中心化的分布式环境中进行通信。 

正如上述讨论所显而易见的，所有通信的核心是 XML。SOAP 和 WSDL 都依赖于 XML。 

我们都曾使用过或至少听说过远程过程调用 (RPC)；RMI（远程方法调用）、CORBA、DCOM、IIOP 等网络通信协议。所有这些技术都有相同的目的——实现调用远程机器上的函数/对象。那么 Web 服务（或 SOAP）与这些现有技术有何不同？主要区别在于 SOAP 使用 HTTP/HTTPS 协议；而其他所有技术都使用专门的协议进行分布式通信。微软通过这种简化的方法，试图为分布式编程世界带来理性和统一。分布式应用程序高度依赖 JNDI 查找、RMI、CORBA、IIOP、可序列化和其他复杂性。借助 Web 服务和 .NET 开发工具；微软为我们提供了一种更简单的开发分布式应用程序的方法。那么有什么诀窍呢？明显的诀窍是，这是一种 ASP.NET 特有的技术（至少目前是这样）；但随着时间的推移，SOAP、WSDL、DISCO 必将获得更广泛的接受。  

根据微软的测试，使用 ADO.NET 和 Web 服务开发的 ASP.NET 应用程序比使用 JAVA、JSP、Servlet 和 EJB 开发的等效应用程序效率高很多倍。[1]

请注意，.NET 没有 EJB 的直接对等项。因此，将 Web 服务视为 EJB 的对等项是不正确的。然而，Web 服务可以提供 EJB 的部分功能。

有了 .NET，微软遵循了一个指导原则——*尽可能简单*。Web 服务也不例外。请看下面的示例，并亲自判断开发 Web 服务有多么容易。并将其与开发 ActiveX 自动化服务器的“容易”程度；或者开发 EJB 的“容易”程度进行比较。

Web 服务示例

打开任何文本编辑器，输入以下 Visual Basic 代码，然后将文件保存为 “.asmx”扩展名。 

Imports System
Imports System.Web.Services
Imports Microsoft.VisualBasic
Public Class HelloWorld : Inherits WebService
    Public Function <WebMethod()> GreetTheUser(strUserName as String)  as String
        Select Case strUserName
            Case "Kashif Manzoor"
                return "Hello Author"
            Case "Amna Kashif"
                return "Hello Ms. Amna Kashif"
            Case "Ahmed Luqman"
                return "Hello little Ahmed"
            Case Else
                return "Hello Stranger"
        End Select
    End Function
End Class

前三行导入了所需的类。Import 类似于 Java 中的 import 或 C/C++ 中的 #include。其余代码不言自明。请注意，该类继承了内置的 Web 服务类；这是强制性的。另请注意，该函数声明为 <WebMethod()> 关键字，这表明该函数可以从 Web 通过 Internet 调用。您可以在类中添加其他私有函数，但这些函数不对外部世界公开。 

就这样！！！您已经成功创建了第一个 Web 服务。尽管该服务只是接受一个名称并返回一个问候语；但这足以让您领略 Web 服务。现在可以从您的 ASP.NET 代码访问此 Web 服务。本文无意详细解释 ASP.NET 或 Web 服务；有兴趣的读者应查阅 ASP.NET 手册或访问 MSDN 网站了解更多详情。 

将您的 “.asmx” 文件部署到支持 Web 服务的应用程序服务器（如 IIS）。然后打开一个支持 Web 服务的浏览器，如 IE。输入文件的适当 URL。如果文件在默认 Web 应用程序文件夹中，则 URL 为“https:///HelloWorld.asmx”。您认为会发生什么？您将看到一个格式良好的网页，其中包含 GreetTheUser() 方法的详细信息。并且在页面底部会有一个编辑框，您可以在其中输入“strUserName”然后按旁边的按钮。完成此操作后，您将收到问候字符串作为 XML 文档。这是一个新颖而绝妙的功能。  

在这里，我们不要对 Sun 的技术不公平。制作一个 EJB（至少是无状态和有状态 EJB）并不比上面的例子复杂。使 EJB 棘手的是部署、JNDI 查找、Stub 和支持 EJB 的应用程序服务器。凭借微软的“即点即用”方法以及 Visual Studio.NET 附带的易于使用的实用程序，部署任何 .NET 应用程序都极其简单。 

总而言之，Web 服务是一个演进的思想，而不是一个革命性的思想；它只是另一个分布式开发工具，恰好非常易于使用。将 Web 服务集成到 ASP.NET 中，使 ASP 达到了一个新的尊重水平。Web 服务已经开始获得普及，并且也被集成到了 Java 平台中。访问 http://java.sun.com 获取 Java 平台 Web 服务支持的最新信息。 

返回顶部 

Web 窗体 

正如 Win Forms 为桌面应用程序提供统一的 GUI 开发方式一样，Web 窗体为 Web 应用程序提供类似的工具。Web 窗体作为 ASP.NET 的一部分在 .NET 中引入。Web 窗体是一个窗体引擎，提供基于浏览器的用户界面。 

要欣赏 Web 窗体，您可以考虑当前 Web 应用程序中的 GUI 如何呈现。GUI 是使用 HTML 标签呈现的。（例如，<input type=text name=editbox1 maxlength=10 size=10 >，将在网页上绘制一个编辑框）Web 窗体还可以根据浏览器的功能，智能地使用 HTML、DHTML、WML 等来绘制网页上的控件。Web 窗体还可以包含这些控件背后的逻辑。就像在 VB 应用程序中一样，您可以将代码与网页上的按钮关联起来，当按钮被按下时，该代码将在服务器上运行。这与客户端上运行的脚本相反。这种方法与 Java 方法不同。在 Java 中，程序员可以通过 JavaScript 和 Servlet 模拟此功能。但有了 Web 窗体，这一切都是透明完成的。Java 程序员可以认为每个 HTML 控件都有其专用的“Servlet”在后台运行。每次控件收到任何感兴趣的事件（例如，按钮被按下、选择已更改等）时，都会调用此特定“Servlet”。这导致代码更清晰，并且表示层和业务逻辑层之间实现了出色的分离。 

Web 窗体由两部分组成——一个模板，其中包含所有 GUI 元素基于 HTML 的布局信息；以及一个包含要链接到控件或 GUI 元素的所有逻辑的组件。这提供了一个整洁的表示层和应用程序逻辑层分离。

GUI 将在客户端呈现，而链接到 GUI 元素的代码将在服务器端运行（非常类似于在 JSP 上按下按钮并响应调用 Servlet。但有了 Win Forms，这一切变得极其简单）。Web 窗体集成到 ASP.NET 中，是为了将 ASP 提升到一个新的水平，使其能够严肃地挑战 JSP。 

Web 窗体的另一个优点是，它可以被构建得足够智能，以支持各种各样的浏览器。如果浏览器是 IE 5.5，同一个 ASP 页面将使用 DHTML 进行渲染。但如果浏览器是 Netscape，网页将使用 HTML 标签进行渲染；如果页面是通过 WAP 设备访问的，同一个页面将使用 WML 标签进行渲染。

ASP 相对于 Java 的一个明显缺点是 ASP 代码维护起来是一场噩梦。而 Java 程序员可以使用 Java Beans、Tags 以及 Servlet 来实现表示层和业务层分离——ASP 程序员没有这样的机制。通过 ASP.NET，微软引入了 Web 窗体的概念，提供了这种表示层-业务层分离： 

1. ASP.NET Web 窗体提供了一种简单而强大的方式来构建动态 Web UI。
2. ASP.NET Web 窗体页面可以定位任何浏览器客户端（没有脚本库或 Cookie 要求）。
3. ASP.NET Web 窗体页面提供与现有 ASP 页面的语法兼容性。
4. ASP.NET 服务器控件提供了一种简单的方法来封装常用功能。
5. ASP.NET 附带 45 个内置服务器控件。开发人员还可以使用第三方构建的控件。
6. ASP.NET 模板提供了一种简单的方法来自定义列表服务器控件的外观和感觉。
7. ASP.NET 验证控件提供了一种简单的方法来进行声明式客户端或服务器数据验证。

 对于那些（像我一样）主要因为 ASP 的意大利面条式代码而转向 Java 进行 Web 开发的人来说——ASP.NET 值得探索。因为它引入了一些令人兴奋的新方法来编写干净的代码（我个人发现 Web 窗体是一个令人兴奋的新概念——在 Java 平台中没有直接的对等项）。

返回顶部 

Windows Forms

Windows 窗体（也称为 Win Forms）用于创建 Windows 桌面应用程序的 GUI。Win Form 的概念借鉴自 Windows Foundation Classes (WFC)，后者曾用于 Visual J++。Win Form 提供了一种集成且统一的 GUI 开发方式。它具有丰富的 Windows 控件和用户界面支持。 

程序员使用无数类和函数来处理 GUI。VC++ 中的 MFC、C++ 中的直接 API 和 VB 中的 VB Forms Engine 只是处理 GUI 的不同方式的几个例子。 

简单来说——Win Form 只是另一组专门处理 GUI 的包装类。Win Form 类封装了 Windows 图形 API。现在程序员无需直接使用 Windows 图形 API；并且由于 Win Form 已成为 .NET 类框架的一部分；所有编程语言都将使用相同的 Win Form 类。这将使程序员摆脱学习不同 GUI 类/工具的需要。Win Forms 是 System.Winforms 命名空间的一部分。 

使用 Win Forms，我们可以创建一个统一的用户界面，并在 VC++、VB、C# 中使用它。使用 Visual Studio.NET，只需通过将控件拖放到窗体上即可设计 GUI（这是所有 VC++ 和 VB 程序员都熟悉的）。现在您可以在 VB、VC++ 或 C# 中使用同一个窗体。这一切都得益于 Visual Studio.NET 使用 System.Winforms 命名空间来绘制 GUI。并且任何具有适当 CLS 合规性的语言都可以直接使用此窗体。 

返回顶部 

各种 .NET 语言 - VB.Net、ASP.NET、C#、J#、VC.NET

Sun 打算将 JVM 作为单一语言虚拟机来呈现。也就是说，只有 Java 程序才能转换为字节码（.class 文件），然后提交给 JVM，JVM 对程序进行解释并在宿主机器上运行。尽管概念上，任何语言都可以编译成 Java 字节码，然后输入 JVM；但 Sun 并不鼓励这种方法。尽管 Sun 在这方面缺乏主动性，但许多研究人员和公司已经开发了遵循此方法的语言。Sun 将 Java 视为“一种语言适用于所有”的愿景，既有支持者也有批评者[5]。 

有了 CLR，微软采取了更自由的政策。微软自己也发展/开发/修改了许多编程语言，以符合 .NET CLR。 

尽管 Visual C++ (VC++) 已经进行了修改以纳入 .NET；但 VC++ 仍然保持其平台相关编程的地位。添加了许多新的 MFC 类；程序员可以选择使用 MFC 并将程序编译成特定于平台的.exe 文件；或者使用 .NET Framework 类并编译成平台无关的 MISL 文件。程序员还可以通过指令指定何时使用“不安全”的代码（绕过 CLR 的代码，例如使用指针）。

ASP 也是一种得到显著改进的语言。大多数程序员都知道 ASP 不如 JSP；微软试图通过引入 ASP.NET 来扭转局面。ASP.NET 大量使用 Web 服务。Web 服务是一个开放标准，JSP 可以使用 Web 服务（Sun 的官方网站提供了 Web 服务的详细信息以及它们如何被集成到 Java 平台中）。ASP.NET 中引入了许多其他功能，使其成为理想的分布式编程工具，并能够与 JSP 相抗衡。ASP 代码在 <% %> 标签内，被编译成 .NET Framework（类似于 JSP 代码被编译成 servlet）。这种方法与 ASP 中 <% %> 的处理方式不同。ASP.NET 已由微软增强。 

在所有 .NET 语言中，Visual Basic.NET (VB.NET) 可能是变化最大的语言之一。现在 VB.NET 可以被认为是一种完整的面向对象语言（与其以前的“半面向对象半面向对象”的地位相反）。 

微软还开发了一种全新的编程语言 C#（C Sharp）。该语言充分利用了 .NET。它是一种纯面向对象的语言。Java 程序员可能会发现该语言的许多方面与 Java 相同。如果您是微软技术的新手——这种语言是进入 .NET 阵营的最简单方式。虽然 VC++ 和 VB 的爱好者会坚持使用 VC.NET 和 VB.NET；但他们可能会通过转向 C# 来提高生产力。C# 的开发是为了充分利用 .NET 的所有细微之处。Java 程序员学习 C# 的学习曲线非常小。微软还推出了**Microsoft Java 语言转换助手**——这是一个工具，可以自动将现有的 Java 语言源代码转换为 C#，供希望将其现有应用程序迁移到 Microsoft .NET Framework 的开发人员使用。

微软还开发了 J#（Java Sharp）。C# 可能与 Java 相似，但并不完全相同。正是出于这个原因，微软开发了 J#——J# 的语法与 Visual J++ 完全相同。微软与 Sun 在 Visual J++ 上的法律纠纷日益激烈——迫使微软停止了 Visual J++。因此，J# 是微软对 Visual J++ 的间接延续。据报道，将一个中等规模的 Visual J++ 项目完全移植到 J# 只需几天的时间。 

微软鼓励第三方供应商使用 Visual Studio.Net（于 2002 年 2 月 13 日发布）。第三方供应商可以为不同的语言编写编译器——将语言编译成 MSIL（Microsoft Intermediate Language）。这些供应商无需开发自己的开发环境。他们可以轻松地使用 Visual Studio.NET 作为其 .NET 兼容语言的 IDE。一家供应商已经生产了 COBOL.NET，它可以与 Visual Studio.NET 集成并编译成 MSIL[3]。理论上，这样就可以出现一种 Java 编译器，它编译成 MSIL 而不是 Java 字节码；并使用 CLR 而不是 JVM。然而，由于 Sun 可能提起的法律诉讼，微软并未追求这一点。

返回顶部 

未来为我们准备了什么？

尽管 Visual Studio.Net 的 Beta 版已经存在了两年多；它于 2002 年 2 月 13 日正式发布。 .NET 的未来非常有前途。凭借 .NET，微软已偏离其长久以来的“专有”理念。微软一直致力于推出优秀的工具——但这些工具不幸地使用了专有技术。DNA、COM、DCOM 不受欢迎的原因之一是它们都基于专有的微软二进制格式。微软从其错误中吸取了教训；.NET 以 ASCII 为基础的 XML 为基础。微软已将 C# 和 CLI 标准化提交给 ECMA，ECMA 于 2001 年 12 月 13 日批准了 C# 和通用语言基础设施 (CLI) 规范为国际标准。ECMA 标准将被称为 ECMA-334 (C#) 和 ECMA-335 (CLI)。还有一个关于 CLI 的技术报告，将被称为 ECMA TR84。此外，ECMA 还批准了这些规范的快速通道提交给 ISO。这是微软 .NET Framework 被业界广泛接受的巨大一步。

目前，CLR 仅在 Windows 平台上可用。.NET 只有在 CLR 可用于其他平台时，才能挑战 Java。Corel 正在开发一个“Port Project”——旨在将 .NET Framework 移植到 LINUX。另一家名为 XIMIAN 的公司也在开发一个名为“Mono”的类似项目。有了第三方项目，我们很快就能在各种非 Windows 平台上获得 .NET 版本。

未来，我们可能会看到 J2EE 和 .NET 相互追逐，没有任何一种技术能够完全取代另一种。历史上，微软平台被认为不适合企业解决方案——而它被认为是独立应用程序的完美工具。另一方面，Java 平台一直被认为适合企业应用程序，而对于独立应用程序则被认为速度慢且效率低下。随着 Java 和 .NET 之间的良性竞争，我们可能会看到更好的应用程序平台。作为一个程序员——我们不会损失任何东西。无论 .NET 比 J2EE 更受欢迎还是反之——编程方面保持不变。无论您是使用 C#、Java 还是 J# 编程——语法（本质上）都是相同的——并且由于 .NET 和 Java 框架类之间的相似性，平均程序员只需一个月左右的时间就可以从一个切换到另一个。 

作者认为 .NET 应该被视为程序员工具箱中一个有价值的补充。在 .NET 中，我们又多了一个可用的工具，如何使用它、何时使用它都由我们自行决定。 

返回顶部

参考文献

• .NET 和 J2EE 应用比较
• C# 简单化，作者 Vijay，BPB 出版社
• Introducing .Net，作者 Wrox Press。ISBN：81-7366-159-6
• Opening up .NET，Michael Otery 撰写，2002 年 1 月《Windows & .NET》杂志
• JVM 和 CLR ，作者 Jon Udell，Byte Magazine
• C# 和 CLI 标准化 
• 编译器、解释器、JVM 和 CLR 简介 ，作者 Kashif Manzoor
• Mastering Enterprise JavaBeans and the J2EE，作者 Ed Roman，John Wiley and Sons, Inc。

 作者非常乐意收到您对本文的评论/建议/批评。本文使用的产品和技术名称是各自开发者/所有者的注册商标。