ajax 的 java 对象序列化.docx

《ajax 的 java 对象序列化.docx》由会员分享，可在线阅读，更多相关《ajax 的 java 对象序列化.docx（20页珍藏版）》请在第壹文秘上搜索。

1、ajax的java对象序列化面对Java开发人员的Ajax:Ajax的Java对象序列化在AjaX应用程序中序列化数据的五种途径假如您正在运用异步JavaScript和XM1.（Ajax）进行JavaWeb开发，那么您最关切的问题可能就是把数据从服务器传递给客户机。在面对Java开发人员的Ajax系列的其次篇文章中，PhilipMcCarthy介绍了Java对象序列化的五种方式,并供应了选择最适合应用程序的数据格式和技术所须要的全部信息。在这个系列的第一篇文章中，我介绍了Ajax的构造块：如何用JavaScriptXM1.HttpRequest对象从Web页面对服务器发送异步恳求。如何用Jav

2、aservlet处理和响应恳求（向客户机返回XM1.文档）。如何在客户端用响应文档更新页面视图。这一次，我将接着探讨Ajax开发的基础学问，但是将侧重于很多JavaWeb开发人员最关切的问题：为客户机生成数据。多数JaVa开发人员已经把模型-视图-限制器（MvC）模式应用在他们的Web应用程序上。在传统的Web应用程序中，视图组件由JSP或者其他表示技术（例如VeIOeity模板）构成。这些表示组件动态地生成全新的HTM1.页面，替代用户以前正在查看的页面，从而更新用户界面。但是，在JavaWeb应用程序运用jaxUI的状况下，基于从XM1.HttpRequest的响应接收到的数据，JaVaS

3、CriPt客户端代码对于更新用户看到的内容负有最终责任。从服务器的角度来看，视图成为它响应客户机恳求而发送的数据表示。这篇文章侧重于可以用来生成Java对象以数据为中心的视图的技术。我将演示可以把JavaBCanS变成XM1.文档的各种方法，并且探讨每种方法的优劣。您将看到为什么XM1.并不总是最好的途径：对于简洁的Ajax恳求来说，传输纯文本更好。最终，我将介绍JavaScript对象标注(JSON)。JSON允许数据以序列化的JavaScript对象图的形式传输,在客户端代码中处理序列化的JaVaSCriPI对象图极为简洁。关于示例我将运用一个示例应用程序和几个用例来演示这里探讨的技术特性

4、和技术。图1显示的极为简洁的数据模型可以表示示例用例。这个模型代表在线商店中的顾客帐户。顾客拥有以前订单的集合，每个订单包含几个商品。图1.简洁的对象模型虽然XM1.HttpRcquest对于发送数据运用的格式没有做任何限制，但是对于多数目的来说，只发送传统的表单数据是适合的，所以我的探讨集中在服务器的响应上。响应也可以有基于文本的格式，但是正如它的名字表示的，XM1.HttpRequest具有内置的处理XM1.响应数据的实力。这使XM1.成为Ajax响应的默认选择,所以我们从XM1.格式起先探讨。从Java类产生XM1.把Ajax响应作为XM1.来传递有很多缘由：每个支持Ajax的阅读器都有

5、导航XM1.文档的方法，也有很多服务器端技术可以处理XM1.数据。通过制定一个方案，描述要交换的文档类型，在Ajax客户端和服务器端之间很简洁定义合约，而且假如服务器端架构采纳面对服务的方式，那么运用XM1.也可以允许非Ajax客户机运用您供应的数据。我将考虑从Java对象产生XM1.数据的三种方法，并探讨每种方法的优劣。回页首闩行进行序列化首先，可以从对象图以编程的方式生成XM1.这种方式可以简洁到只是在每个JavaBean类中实现toXml()方法即可。然后就可以选择合适的XM1.API,让每个bean供应表示H己状态的元素，并递归地对自己的成员调用对象图。明显，这种方式无法扩展到大量的类

6、，因为每个类都须要特地编写自己的XM1.生成代码。从好的方面来看，这是一个实现起来简洁的方式，没有额外的配置支出或者更困难的构建过程支出，任何JavaBean图都可以只用几个调用就变成XM1.文档。在本系列前一篇文章的示例代码中，我把XM1.标记字符串连接在一起，实现了toXml()方法。上次我就提到过，这是个糟糕的方法，因为它把确保标记配对、实体编码等工作的负担放在每个toXml()方法的代码中。在Java平台上有几个XM1.API可以替您做这些工作，这样您就可以把精力集中在XM1.的内容上。清单1用Jf)OMAPI实现了在线商店示例中表示订单的类中的toXml()(请参阅图1):清单1.O

7、rder类的toXml()的JI)OM实现publicElementtoXmlO(ElementelOrder=newElement(order)：elrder.SetAttribute(id,id);elOrder.SetAttribute(cost,getFormattedCostO);ElementelDate=newElement(date).addContent(date);elOrder.addConte11t(elDate);ElementelItems=newElement(items);for(IteratorItemiter=iterns,iteratorO;iter.ha

8、sNextO;)elltems.addContent(iter,nextO.toXmlO);elOrder.addContent(ellterns);returnelOrder:在这里可以看到用JDQM创建元素、运用属性和添加元素内容有多么简洁。递归地调用复合JavaBean的toXml()方法是为了取得它们子图的Element表示。例如,items元索的内容是通过调用Order聚合的每个Item对象上的toXml0得到的。回页首一旦全部的JavaBean都实现了toXml()方法，那么把随意对象图序列化成XM1.文档并返回给Ajax客户机就简洁了，如清单2所示。清单2.从JDOM元素生成XM

9、1.响应publicvoiddoGet(HttpServletRequestreq,HttpServletResponseres)throwsjava.io.IOException,ServletExceptionStringcustld=req.getParameter(username)：Customercustomer=getCustomer(custld);ElementresponseElem=customer.toXmlO;DocumentresponseDoc=newDocument(responseElem);res.SetContentType(application/xml

10、);newXM1.OutputterO.output(responseDoc,res.getWriterO);JDOM再次把工作变得特别简洁。只须要在对象图返回的XMl.元素外面包装一个DoCUment,然后用XM1.Outputter把文档写入servlet响应即可。清单3显示了用这种方式生成的XM1.示例,用JDOMFormat.getPrettyFormat()对XM1.Outputter进行初始化，格式化得特别好。在这个示例中，顾客只做了一个订单，包含两个商品。清单3.代表顾客的XM1.文档?xmlversion=!.Oencoding=UTF-8?customerusername=j

11、immy66realnameJamesHyraxZrealnanicordersorderid=o-11123COSt=$349.98date08-26-2005dateitemsitemid=i55768nameOolong512MBCFCard/namedescription512MegabyteType1CompactFlashcard.ManufacturedbyOoiongIndustriesZdcscriptionPriCC$49.99/price/itemitemid=i74491nameFujakSupcrpix72Camera/namedescription7.2Megapi

12、xeldigitalcamerafeaturingsixshootingmodesand3xopticalzoom.Silver./descriptionpriceS299.99/price/item/items/order/orders/customer自行序列化的不足好玩的是，清单3中的代码展示了让JavaBean把臼己序列化为XM1.的一个主要不足。假设要用这个文档表示顾客的订单历史视图。在这种状况下，不太可能要显示每个历史订单中每个商品的完整说明，或者告知顾客他或她自己的姓名。但是假如应用程序有一个ProductScarch类，它就是以IIembean列表的形式返回搜寻结果，那么在It

13、em的XM1.表示中包含说明可能会有帮助。而且，Item类上代表当前库存水平的额外字段，在产品搜寻视图中可能就是须要显示的有用信息。但是，不管当前的库存水平是否与当前状况相关（比如对顾客的订单历史来说），这个字段都会从包含Item的任何对象图中序列化出来。从设计的角度来看，这是数据模型与视图生成耦合的经典问题。每个bean只能用一种途径序列化自己，一成不变的方式意味着Ajax交互最终要交换它们不须要交换的数据，因此造成客户端代码要从文档中找到须要的信息更加困难，而且也会增加带宽消耗和客户端的XM1.解析时间。这种耦合的另一个后果就是XM1.的语法不能脱离Java类独立变更。例如，对顾客文档的方

14、案做修改，可能会影响多个Java类,造成它们也不得不做修改和重新编译。我梢后会解决这些问题，但是首先来看一个对自行序列化方式的可伸缩性问题的解决方案：XM1.绑定框架。XM1.绑定框架近些年来，已经开发了多个JavaAPI来简化XM1.文档到Java对象图的绑定过程。多数都供应了XM1.编排和拆解：也就是说，它们可以在Java对象图和XM1.之间执行双向会话。这些框架封装了XM1.处理的全部工作，这意味着应用程序代码只须要处理一般的JaVa类。它们还希望供应有用的协助功能，例如文回页首档验证。笼统来说，这些框架采纳了两种不同的方式：代码生成和对象到XM1.映射。我将分别说明这两种方式。代码生成

15、方式运用代码生成的框架包括XM1.Beans.JAXB.Zeus和JBindoCastor也能运用这项技术。这类框架的起点是描述文档数据类型的XMI.方案。运用框架供应的工具，就可以生成代表这些方案定义类型的Java类。最终，用这些生成的类编写应用程序，表示臼己的模型数据,并通过框架供应的一些协助机制把数据序列化成XM1.o假如应用程序要运用大型XM1.语法，那么代码生成方式是个很好的方法。在数十个类上编写定制XM1.序列化代码的可伸缩性问题由此消退。另一方面，也不再须要定义H己的JaVaBearI。框架生成的Java类通常特别符合XV1.的结构，所以对它们进行编码很难。而且，生成的类变成哑数据容器，因为一般不能向它们添加行为。一般来说，在应用程序代码中要做些妥协，才能很好地处理方案生成的类型。另一个缺陷是假如修改方案，会造成生成的类也要修改，所以也就会对围绕它们编写的代码带来相应的影响。这种类型的XMI,绑定框架在数据拆解时最有.用（例如，运用XM1.文档并把它们转化成Java对象）。除小拥有大型数据模型而且有可能从生成的类中获益，否则基于代码生成的框架对于Ajax应用程序来说可能有很大的杀伤力。映射方式采纳映射方式的框架包括Castor和APaCheC