论是 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 的.NET 构架中配置外部元数据, 这个功能被包括在配置文件 的分级系统中,它能从父系统中继承属性
,这样每个文件会很小,它只记录改变的设定。这就避 免了 J2EE 模型的第二个问题
b. c.
数据库连接池 Windows .NET Framework 中,是根据需要自动建立和管理这些池的。而在 J2EE 模型中,连接池必须被明确配置和管理。 XML Web 服务:在.NET 中建立一个 XML Web 服务就像在类中添加一个属性那样简单。有些基于 J2EE 的产品也想在 Java 中模拟这个功能, .NET 提供更简单的方法来建立和使用可由双方共同操 作的 XML Web 服务。
d.
部署:在.NET 中,要部署一个应用程序,管理员只需要拷贝文件。而在 J2EE 中,管理员必须 将很多编译文件和 JAR、WAR 以及 EAR 绑定,然后在一个特定的服务器部署工具中解开并运行它 们,接着拷贝结果档案。这个多步部署过程意味着典型的编辑/编译/调试循环被大大延