而

Java 和 J2EE（现有的）没有版本识别的类加载器，这就意味着开发者和管理员

不能保证代码被执行时是正确的。或是说，开发者只能靠运气来保证这一点。

b.       Windows .NET Framework 显示了语言层面上的类属性—这就使得编程更加简单。

例如，在源代码中只用一个简单的属性就能把

.NET 组件标志为处理模式。或者说，

一个

.NET 组件和 XML 的串行化可以在一个属性中被定义。这个机制大大简化了许

多编程任务。而

Java 不显示语言层上的类属性，虽然 Sun 公司考虑到要修改 Java 语

言来改变现状。这种变化估计在两三年内才能第一次实现。

c.       .NET 还支持分离数据访问，这主要用于在移动设备或是偶尔联网的场合里运行

的应用程序。数据能被脱机操作，接着再和起始数据重新同步。而不论是

J2EE 还是

J2SE 现阶段都不支持分离数据访问，需要这项功能的 J2EE 开发者必须自己写
“plumbing code”。

d.       为建立基于网络的用户界面，Windows .NET Framework 提供基于事件的模型，

这些模型类似于流行的

Visual Basic 中的智能客户端模型。ASP .NET 模型使得建立、

发布和维护一个基于网络的用户界面变得更加容易。与之形成对比的是，

J2EE 在

JSP 中不支持这样的模型。有一些第三方的扩展程序部分弥补了这些功能，但是它
们的实用性和简便性不能和

ASP .NET 相比。作为一个推荐的 J2EE 附加程序，Java 

Server Faces 可能做到这一点。但这个附加程序并没有包括在 J2EE 的 1.4 版本以前。
而要获得销售商的支持，则又需至少一年的时间。

e.       J2EE 支持一个对象相关的数据映像模型，它被称作 EJB Entity Beans。这样是为了

允许开发者更容易地从一个相关的数据库建立对象模型。然而，实际上把这个想法
编程实现却要面对下列问题：

Ⅰ.易用性：当那些熟知的、正规定义的、被广泛支持的结构化查询语言（SQL）

和开发者的数据相互作用时，开发者不得不放弃它们，而使用一个被称为

EJBQL

的弱定义查询语言。和

SQL 相类似，EJBQL 的功能并不强大（例如，在现有的规

范中，它没有

ORDER BY 的语句，这样开发者就没法使用特定数据库的 SQL 扩

展），而它的语义也没有被正规定义。还有，在对象间建立联系和附属关系十分困
难，而且在对象间和

XML 以及后端之间的数据翻译是手动控制的。

Ⅱ.性能：基于 EJB 系统的性能仍是一个未知数。没有提供公开的基准。客户反

映，得到的性能远远偏离了

Entity Beans，并且转向一个更直接的数据访问策略。这

是

EJB Entity Beans 没有被广泛使用的一个关键因素。

在

Windows .NET Framework 中，数据访问是基于数据集比较的。数据集保存了相关数

据的一个子集，它由一个或多个

SQL 查询语句描述。数据集中的数据可能保存关键的联系，

并且开发者能直接对数据进行操作，能将数据转换成

XML 格式和上次操作的类型，能使

用标准的

SQL 过滤数据等。总而言之，相对于 EJB Entity Beans，.NET 的数据集模型提供一

个更丰富而且简单熟悉的途径。
5）

  简便性

a．

  配置：对于 J2EE，配置是由部署描述信息获得的 XML 格式的文件，它们和

实际执行的商用逻辑代码有明显区别。这种方法有很多问题。第一，考虑到特
定类的元数据，有些代码中的改变和元数据中的改变是相互依赖的。两个独立
文件的同步性要求有可能产生错误。第二，考虑到应用程序层的元数据，在
J2EE 中，没有可以从一个程序继承元数据到另一个程序的途径。与 J2EE 不同，
Windows 的.NET 构架包括了这个功能，使得可以在源代码中直接向类添加属
性，这样就不会产生第一个问题。

Windows .NET 中的元数据模型允许客户自

己添加扩展程序，这样开发者就可以编写和使用自己的属性。为了在

Windows