张家宇-Google Map拼车网中信息撮合系统的设计与实现

学号________________

密级________________

武汉大学本科毕业论文

Google Map拼车网中信息撮合系统的设计与实

现

院（系）名 称：国际软件学院 专 业 名 称 ：软件工程 学 生 姓 名 ：张家宇 指 导 教 师 ：冯晶 教授

二○○九年五月

1

BACHELOR'S DEGREE THESIS OF

WUHAN UNIVERSITY

Design and Realization of Information Marching

in the Google Map Car-sharing System

College ：International Software School Subject ：Software Engineering Name ：Jiayu Zhang

Directed by ：Jing Fen Professor

2

May 2009

郑 重 声 明 （宋体粗体2号居中）

本人呈交的学位论文，是在导师的指导下，独立进行研究工作所取得的成果，所有数据、图片资料真实可靠。尽我所知，除文中已经注明引用的内容外，本学位论文的研究成果不包含他人享有著作权的内容。对本论文所涉及的研究工作做出贡献的其他个人和集体，均已在文中以明确的方式标明。本学位论文的知识产权归属于培养单位。

（宋体4号）

本人签名： 日期：

3

摘要

随着我国人民生活水平不断提高，车辆充斥着整个街道，拼车成为人们不二的选择和流行的词汇。Google Map的不断强化，也不断冲刷着web领域的运用。Google Map与拼车结合在一起必将走在时代的前沿。由于人们对拼车的确定上很难把握，所以有必要就拼车网的撮合系统进行研究和探讨。

本论文以构筑适合与GoogleMap拼车网的信息撮合系统为目标，深入探讨了信息撮合系统的设计与实现。该撮合系统实现了新消息提示，用户评价、以及线路的撮合功能，为用户提供了一整套的信息撮合流程，使用户之间能安全、目的明确的互动交流和评价。

笔者从Ajax、XML、空间数据库等一些技术的简介开始，分析突出空间数据库的优点，对XML解析技术做了详尽的对比，结合介绍了设计模式和SSH的基本运用。然后就项目的开发流程，分析了整个系统的实现过程。具体来说以需求分析入手，结合需求进行了一些相关的技术调研和难点解析；再对数据库进行了设计；然后就各功能模块进行了设计，将设计模式中的单例模式、观察者模式和SSH框架的运用结合到设计中；然后在结合设计的基础上对系统进行了。

基于SSH构架的Google Map拼车网信息撮合系统具有结构灵活、易于维护、扩展性好的优点。

关键词：AJAX；XML；解析；空间数据库；SSH；设计模式

4

ABSTRACT

With the rising standard of living of our people, the whole street full of vehicles, car-sharing has become the best choice of the people and the popular vocabulary. Continued to strengthen the Google Map have been scouring the area of a web application. The application combining Google Map and car-sharing will be at the forefront of the times. As people in the car-sharing, it is difficult to define the success, so it is necessary to study and discuss the Information Marching System.

In this paper, in order to build the information marching for the GoogleMap car-sharing System, Deeply analyze the design and implementation of the information matching system. The systems bring together the news tips, users rating, as well as matching of roads, so that the users can communicate and evaluate safely with purposeful interaction.

The author introduces the technique of Ajax, XML and spatial databases, analysis the

advantages of spatial databases, make a detailed comparison for the XML parsing technologies, and introduces the usage of design patterns and SSH structure. In accordance with the development process of the project, the author analyzes the implementation of the entire system. Specifically analyzing the demand, combined with the demand for a number of related technology research and difficult to resolve; re-design the database; then the functional module design, the design of single-mode case model, the observer model and SSH into the use of the framework design; and then combined on the basis of the design system. The Google Map Car-sharing System based on SSH framework information system has a flexible structure, easy maintenance, good scalability.

Key words: AJAX, XML, parsing, spatial databases, SSH, design patterns

5

目录

第一章 概述

1.1 课题研究背景 ...................................................... 1 1.2 课题研究目的及意义 ................................................ 1 1.3 课题的国内外研究现状 .............................................. 2 1.4 本文研究内容及技术路线 ............................................ 2

1.4.1 本文研究内容与组织结构 ............................................................................... 2 1.4.2 技术路线 ........................................................................................................... 3 本章小结 ............................................................... 4 第二章 系统涉及技术及其分析

2.1 AJAX技术及其特点 ................................................. 5

2.1.1 AJAX概述 ....................................................................................................... 5 2.1.2 AJAX定义 ....................................................................................................... 6 2.1.3 AJAX核心技术 ............................................................................................... 6 2.1.4 AJAX工作原理 ............................................................................................... 8 2.2 XML技术 ......................................................... 10

2.2.1 XML的历史与背景 ....................................................................................... 10 2.2.2 XML系列简述 ............................................................................................... 11 2.2.3 XML语法简述 ............................................................................................... 11 2.2.4 XML解析技术 ............................................................................................... 12 2.3 空间数据库技术概述 ............................................... 15

2.3.1 OpenGIS简介.................................................................................................... 15 2.3.2 MySQL中对OpenGIS的支持 ..................................................................... 17 2.4 相关设计模式概述 ................................................. 20

2.4.1 设计模式的发展历史 ..................................................................................... 20 2.4.2 设计模式的定义与基本要素 ......................................................................... 21 2.4.3 设计模式的作用 ............................................................................................. 22 2.4.4 Gof设计模式的简介 ..................................................................................... 22 2.5 SSH构架简介 ..................................................... 25

6

本章小结 .............................................................. 25 第三章 信息撮合系统的分析及设计

3.1 需求分析 ......................................................... 26 3.2 技术调研 ......................................................... 27

3.2.1 新消息提醒的及时性体现 ............................................................................. 27 3.2.2 数据库存储类型的选择 ................................................................................. 28 3.2.3 消息表的设计 ................................................................................................. 29 3.2.4 前后台新消息的交互数据 ............................................................................. 29 3.2.5 撮合时信息的处理 ......................................................................................... 30 3.2.6 线路撮合成功后的评价生成 ......................................................................... 30 3.3 数据库的设计与封装 ............................................... 30

3.3.1 用户相关表的设计 ......................................................................................... 30 3.3.2 线路相关表的设计 ........................................................................................ 31 3.3.3 消息相关表的设计 ......................................................................................... 32 3.3.4 撮合相关表的设计 ......................................................................................... 32 3.3.5 数据库的整体设计 ......................................................................................... 33 3.3.6 通过Hibernate实现数据库的封装 ............................................................... 35 3.4 信息撮合系统的整体设计 ........................................... 36

3.4.1 线路撮合的设计 ............................................................................................. 36 3.4.2 评价模块的设计 .............................................................................................. 37 3.4.3 新消息提示的设计 .......................................................................................... 38 3.4.4 消息获取的设计 ............................................................................................. 38 本章小结 .............................................................. 38 第四章 信息撮合系统的实现方法及关键技术

4.1 线路撮合的后台实现 ............................................... 39 4.2 评价模块的实现 ................................................... 42

4.2.1 评价记录的生成 ............................................................................................. 42 4.2.2 评价记录的提交 .............................................................................................. 43 4.3 ............................................................ 新消息提示的实现 ......................................................................... 44

7

4.4 ...............................................................消息获取的实现 ......................................................................... 45

4.4.1 消息的后台获取的实现 .................................................................................. 45 4.4.2 消息的前台解析的实现 .................................................................................. 46 本章小结 .............................................................. 47 第五章 系统功能展示

5.1 新消息提示模块的实现效果 ......................................... 48 5.2 评价模块的实现效果 ............................................... 48 5.3 乘客申请模块的实现效果 ........................................... 50 5.4 车主邀请模块的实现效果 ........................... 错误！未定义书签。 本章小结 .............................................................. 52 第六章 总结与展望

6.1 总结 ............................................................. 53 6.2 展望 ............................................................. 53 参考文献 .................................................................. 54 致谢 ...................................................................... 57

8

第一章 概述

1.1 课题研究背景

相同路线的人乘坐同一辆出租车上下班，上学及放学回家，节假日出游等，车费由乘客平均分摊即为拼车。拼车是一个新兴的事物。根据报导，韩国、希腊及欧美国家的出租车已尝试“合乘制”。在美国，多人乘坐同一辆出租车是被鼓励和支持的。既有利于环保，有利于缓解拥挤的城市交通，又有利于乘客。在我国浙江、北京、广州等五十多个城市已经开拓了拼车服务并产生了注册服务机构国内外要就现状。

为了用户更加方便灵活的享受拼车的服务，本项目针对用户拼车需求，利用Google Maps API将拼车信息，拼车信息在地图上进行显示，并在地图上标注路线，便于直观的搜索和匹配拼车需求信息。本系统将着重于用户信息撮合方面的实现。

随着Internet在全球的迅猛发展，电子商务作为21 世纪信息时代经济活动全新的技术手段和方法，已成为其最广阔的应用领域。在这些电子商务特别是B2B 电子商务平台的应用中，越来越多地提供了E-Market的功能，而在E-Market中，供需双方的信息匹配又是不可或缺的内容。传统的电子商务一般只注重信息的搜索，提供给客户的撮合的功能较少，只在一定的规则下给出定性的查询结果，并不提供细致的定量分析。而随着商务活动的日趋繁忙，人们希望平台提供更多的信息交互和对业务进行撮合的功能。

在我国这样一个信息不对称的环境下，信息的掌握和交流往往较其他的生产要素来得更加重要，一场交易的成败往往就依赖于一条好的消息渠道，将有效信息尽快地传达给用户至关重要，由此可见信息在传递和交互过程中的速度、安全性是多么重要。那么根据这些信息进行撮合也就扮演了重要的角色。

1.2 课题研究目的及意义

本课题的研究主要是针对拼车网中信息撮合系统的设计与实现进行，以设计和实现一个针对GoogleMap拼车网的信息撮合系统为目的。在撮合系统的设计与实现过程中，尽量地使系统达到高类聚低耦合，使系统更具扩展性，实现更好的用户体验，让拼车的多方之间能够尽可能的撮合。

1

对与我们的GoogleMap拼车网而言，信息的交互尤其重要。用户在基于搜索的情况下，选择自己最有可能参与的拼车线路，信息撮合系统把这些选择传递给发布线路的人??使消息在他们之间来回传递，最终达到线路撮合成功的结果。在我们的拼车网中，信息撮合系统起到非常重要的作用。正是由于撮合系统的存在，才使得拼车的多方有了一个交流的平台和一个既定的撮合流程，让拼车的多方之间不必为了何时撮合成功而苦恼。用户只需要查看系统提示的新消息，按照简单的提示就可以达到满意的撮合结果。同时信息撮合系统提供评分的机制，不用太担心有不诚实的情况存在，因为在我们拼成网中，如果用户不诚实，同行者将给予扁评，积分上就会有所体现。

正是因为我们的拼车网有必要有一个上面所说的撮合系统，才使得我的这个课题得以进行。可以说针对本课题而言，项目是研究的驱动。

拼车网中撮合系统的实现在web运用领域尚属比较新的范畴，所以本课题的研究也有很高的使用价值。

1.3 课题的国内外研究现状

关于拼车网的研究与运用在web领域非常的广泛，例如拼车/顺风车信息网、拼车啦、顺风车网、上海百姓网、温州拼车网、中国拼车族、CarSharing.net和google生活频道等。但是这些网站在用户的信息撮合这几块都只是简单的登录后报名，然后可以查看别人的联系方式，同时给发布线路的人发送申请者的信息，这样用户之间的交流和撮合是和系统无关的，用户在私底下解决。这些网站在撮合这一块几乎没有做努力。所以将撮合系统运用到拼车网中尙属于比较新的组合。

撮合系统在各E-Market中的运用相对比较广泛，最好的例子就是C2C的网站，例如淘宝、拍拍等网站。这些网站充分考虑了交易中会出现各种情况，提供了交易的双方之间通讯的平台和交易的流程，也为交易提供了支付手段。淘宝年交易量过千亿已经无懈可击地证明了他们的撮合系统的强大

1.4 本文研究内容及技术路线

1.4.1 本文研究内容与组织结构

第一章是概述，介绍本文的研究背景、课题的中外研究现状、课题的研究意义等。第二章将要介绍了本文方法所设计到的相关技术，这些技术将是支撑整个系统的基础，非常重要。第三章介绍了信息撮合系统的分析与设计，对系统的需求进行了分析，对项目实现过程中将

2

要面临的技术难点进行了突破，对整个系统进行了设计，为整个系统的实现提供了实现基础，是整个系统的核心思想所在。第四章介绍了信息撮合系统的实现方法及关键技术，主要以流程图的形式显示在实现过程中的编码逻辑，在关键代码的实现上以伪代码的形式展示，主要体现了编码过程中的基本思路。第五章介绍了本系统实现后的功能展示。第六章主要是对本文进行一次总结和对未来工作的一些展望。

本文的组织结构图1-1所示。

概述系统关键技术及其分析信息撮合系统的分析及设计信息撮合系统的实现方法及关键技术系统功能展示总结与展望图1-1 文档结构图

1.4.2 技术路线

本系统实现的技术路线图：

3

撮合系统需求分析技术调研需要实现的功能掌握所需的技术分析功能、细化需求技术难点分析查阅资料解决编写代码系统设计编写代码系统实现 图1-2 本系统实现的技术路线图

本章小结

本章就课题的背景、课题的研究目的意义、国内外研究现状、研究内容及技术路线做了一番概述。对本文起到概括作用。在接下来的一章中，主要介绍本系统在开发过程中所设计的一些关键技术，以及对这些关键技术的分析。

4

第二章 系统涉及技术及其分析

本章将对系统开发过程中涉及到的技术做详尽的阐述和分析，这些技术是系统实现的基础，在系统的开发过程中起到了指导性意义。下面将对这些技术进行逐一地阐述和分析。

2.1 AJAX技术及其特点

2.1.1 AJAX概述

当前应用程序的开发模式主要有客户端/服务器(C/S)模式和浏览器/服务器(B/S)模式，C/S模式的应用程序优点是不存在网络数据传输的瓶颈束缚，客户端相应速度快，界面元素丰富，动态性好，操作效率高等，但其缺点是客户端需要分别安装，增加了系统实施的成本，也正因为客户端是分别安装的，其版本更新就成了一个很大的问题；B/S模式由于不需要可以安装客户端(使用浏览器代替客户端)，所以不存在客户端软件的安装和更新的问题，但由于存在于服务器端的网络数据传输，整个操作过程中会存在一个“发出请求—等待服务器相应—获得操作结果”的过程，因而客户端用户会明显地感觉到操作延迟。

AJAX的出现极大的缓解了B/S模式应用程序的上述不足，它的富客户端的思想和异步操作特性使得B/S应用程序响应时间更快，界面更友好，更加接近甚至超过C/S模式的客户端。IT界首次出现AJAX的概念是在2005年2月，当时Adaptive Path公司的Jesse James Garrett在互联网上发表了一篇名为《AJAX: A New Approach to web Application》的论文。在这篇文章中，Garrett提出AJAX是Asynchronous JavaScript And XML的缩写，并提到Web应用程序与传统桌面程序之间的差距正在被缩小，以及如何从真正意义上消除这两种应用程序之间的界限。他引入了一些新的概念，并以Google公司的几个成型产品如Google Maps和Google Suggest等作为示例，详细阐述了如何将传统的桌面应用程序模型转移到web上。

AJAX与传统Web界面在实现上的异同如图2-1

5

图2-1 AJAX与传统Web界面在实现上的异同

2.1.2 AJAX定义

在上述文章中，Jesse James Garrett这样定义为Ajax: Ajax不是一种新技术。实际上，它由几种蓬勃发展的、拥有各自的产权的技术以一种强大的新方式组合而成。具体来说，Ajax包含：

? 使用XHTML和CSS技术进行标准化显示和表达；

? 使用文档对象模型(Document object Model，DOM)技术进行动态的显示和交互； ? 使用XML和XSLT进行数据的交互操作和控制； ? 使用XMLHttpRequest与服务器进行异步数据通信； ? 使用JavaScript技术将所有其他组件绑定在一起。 2.1.3 AJAX核心技术

在AJAX的各个组件中，最为重要的当属JavaScript、DOM、CSS和XMLHttpRequest四者，以下分别进行简单介绍：

1. JavaScript

JavaScript是一种强大的编程语言，用于开发交互式的Web页面。创建JavaScript的初衷是为了帮助开发人员动态地修改页面上的标记，为客户提供更丰富的体验。当

6

人们越来越认识到页面也可以当作对象时，文档对象模型DOM应运生。开始的时候，JavaScript和DOM紧密交织在一起，但最后还是分开来各自发展了。

JavaScript的定义可以从两个方面来说明：①JavaScript是一种通用的脚本编程语言，也是一种基于对象和事件驱动并具有安全性能的脚本语言；②JavaScript代码嵌入在HTML页面中，它把静态页面转变成支持用户并响应事件的动态页面。 2. DOM

文档对象模型(Document Object Model，DOM)是一个跨平台的、可适应不同程序语一言的文件对象模型，它采取直观的方式，将HTML和XML文档进行模型化处理，提供了存取和更新文档内容、结构和样式的编程接口。DOM要比DTHML对象模型功能更全面。

DOM由w3C制定，它可以分为三个部分:核心、XML和HTML。其中核心DOM定义了任意文档结构的标准对象集合；HTMLDOM和用户的关系最为紧密，用户通常使用存在于HTML中的JavaScript脚本来操纵DOM。DOM的出现使开发人员拥有了创建多样化、功能强大的应用程序的能力。在AJAX应用开发中，采用DOM的方式动态修改页面，进行局部刷新，从而实现页面的动态更新效果。

DOM的出现使开发人员拥有了创建多样化、功能强大的应用程序的能力。在AJAX应用开发中，采用DOM的方式动态修改页面，进行局部刷新，从而实现页面的动态更新效果。 3. CSS

CSS的全称是Cascading Style Sheets，中文翻译为“层叠样式表”。它是一种制定网页的技术。它可以轻松地控制页面的布局，使页面的字体变得更美观，更容易编排，使页面真正赏心悦目；以前用过图片转换实现的功能，现在只用CSS就轻松实现，另外，CSS有多种使用方法如外部链接式、嵌入式或直接插入式等，使用起来非常便捷。

4. XMLHttpRequest

AJAX技术之中，最核心的技术就是XMLHttpRequest， XMLHttpRequest为运行于浏览器中的JavaScript脚本提供了一种在页面之内与服务器通信的手段。页面内的JavaScript可以在不刷新页面的情况下从服务器获取数据，或者向服务器提交数据。而在这个技术出现之前，浏览器与服务器通信的唯一方式就是通过表单的提交，这一般都会带来一次全页面的刷新。

7

下面这段简单的代码展示了如何在客户端页面中创建一个XMLHttpRequest对象：

2.1.4 AJAX工作原理

AJAX典型的工作过程如下所示：在会话的开始，浏览器加载了一个Ajax引擎，其采用JavaScript编写，主要负责绘制用户界面以及与服务器端通讯。用户使用某个基于AJAX的功能后，引擎便开始异步访问服务器，而不用耽误用户的时间。当访问结束后，Ajax会将结果传回，客户端此时可以根据结果或者提示用户某些信息，或者为用户提供某些服务。AJAX技术与传统Web操作间之所以能够产生如此大的差异，关键在于AJAX中“异步”的特性，这个过程可用图2-2。

8

图2-2 Compare with synchronous and asynchronous web application（传统web应用的同步交

互过程和AJAX应用的异步交互过程的比较）

AJAX技术特点和优势

Ajax作为一种web领域广泛运用的技术，有许多传统web技术无法比拟的优点，主要体现在一下几个方面：

? 增加用户愉悦的体验。应为可以不刷新整个页面更新信息，所以给用户的视觉效果比以前的WEB系统大大提高，系统地响应速度也得到很大的提高；

? 减轻了网络负担。因为很多情况下不需要真个页面刷新，网络上只需要以XML格式或者其他自定义的格式传递所需的数据即可，大大的减小了网络上数据的传送量；

? 弱化了桌面程序和服务器程序的差别。提出了“富客户端”的概念，在WEB客户端也能处理一些事情；

? 减轻了服务器负载。对一些大型的网站，服务器的资源非常宝贵，AJAX技术能将部分处理分担在客户端，从而减轻了服务器端的负担，使得相同的服务器单位时间能提供更多的服务；

? 更新了开发理念。以前一些客户端的特殊效果，比如拖拽，分层展开，及时提醒

9

等等只能在桌面软件上实现，现在通过AJAX技术，这些己经不再困难； ? 使Web程序更加规范。CSS、XML和XSLT被提到了前所未有的高度，使得Web程序的开发更加规范。同时，一些基于AJAX开发的辅助工具也为我们的开发提供了很大的便利。

2.2 XML技术

2.2.1 XML的历史与背景

XML是从1996年开始有其雏形，并向 W3C（全球信息网联盟）提案，而在1998二月发布为W3C的标准（XML1.0）。 XML的前身是SGML（The Standard Generalized Markup Language），是自IBM从60年代就开始发展的 GML（Generalized Markup Language）标准化后的名称。

XML（Extensible Markup Language）即可扩展标记语言，它与HTML一样，都是SGML(Standard Generalized Markup Language,标准通用标记语言)。Xml是Internet环境中跨平台的，依赖于内容的技术，是当前处理结构化文档信息的有力工具。

XML与Access、Oracle和SQL Server等数据库不同，数据库提供了更强有力的数据存储和分析能力，例如：数据索引、排序、查找、相关一致性等，XML仅仅是展示数据。事实上XML与其他数据表现形式最大的不同是：他极其简单。这是一个看上去有点琐细的优点，但正是这点使XML与众不同。

XML与HTML的设计区别是：XML是用来存储数据的，重在数据本身。而HTML是用来定义数据的，重在数据的显示模式。

XML的简单使其易于在任何应用程序中读写数据，这使XML很快成为数据交换的唯一公共语言，虽然不同的应用软件也支持其它的数据交换格式，但不久之后他们都将支持XML，那就意味着程序可以更容易的与Windows、Mac OS, Linux以及其他平台下产生的信息结合，然后可以很容易加载XML数据到程序中并分析他，并以XML格式输出结果。

因为XML是W3C制定的，XML的标准化工作由W3C的XML工作组负责，该小组成员由来自各个地方和行业的专家组成，他们通过email交流对XML标准的意见，并提出自己的看法 (www.w3.org/TR/WD-xml)。因为XML 是个公共格式， (它不专属于任何一家公司)，你不必担心XML技术会成为少数公司的盈利工具，XML不是一个依附于特定浏览器的语言。

10

2.2.2 XML系列简述

XML不仅仅是XML1.1规范，围绕XML的是各式各样的XML标准和产品，他们与XML组合起来解决大量有关把XML引入主流计算的问题，即表现、结构和转换。这些组成了通常所说的XML系列。如图2-3所示，XML从大量的支持技术中产生力量。

图2-3 XML技术序列

2.2.3 XML语法简述

XML文档的基本结构由序言部分（Prolog）和一个根元素（Root element）组成。序言包括了XML声明和DTD（或是XML Schema），DTD和XML Schema都是用来描述XML文档结构，也就是描述元素和属性是如何联系在一起的。根元素（也称文档元素），由文档中的其它所有标记和字符数据组成。元素是XML文档的基本组成部分。

图2-4 XML文档示例

下面是一些基本的语法规则：

? 每个文档有且仅有一个根元素（Root），其它所有元素都是它的子元素。

11

? 每个元素（Element）对的上下文（context）关系要正确。即元素之间必须正确的嵌套。因为XML是半结构化的数据，可以用XML描述树来表示起结构，所以它的逻辑结构和语法都有严格定义（如使用DTD或Schema）。

? 每个元素（Element）都必须有开始和结束标识（‘<’和‘>’）。元素的内容可以是其它的元素、字符数据、字符引用、实体引用、PI、注释和CDATA（Character DATA，字符数据）节，元素也是能够拥有属性的唯一基本类型。 ? 元素的属性值必须由单引号（‘）或双引号（“）包含。 2.2.4 XML解析技术

随着XML越来越广泛地被采用，高效解析XML文档也变得越来越重要，尤其是对于那些要处理大量数据的应用程序，这种技术尤为重要。不正确的解析会导致过度的内存消耗和过长的处理时间，从而有损于可伸缩性。

通常，用于XML解析的API可以分为两大类：基于时间流的API和基于树结构的API（例如DOM）；而基于时间流的API又可以分为“推”模式（比如SAX）和“拉”模式（比如STAX）两种类型。

图2-5 基本的XML解析API

以下针对这三种类型的典型API进行分析比较，指出它们各自的优点和不足之处，从而为接下来的嵌入式XML解析器的设计提供必要的选型依据。

2.2.4.1 DOM

DOM是W3C支持的标准应用程序编程接口（API），是一种与平台和语言无关的接口，

12

DOM采用基于树型的解析技术将XML文档一次性解析，生成一棵位于内存中的对象用以描述该文档。树的节点是一个个对象，通过操作这些对象就能操作XML文档的内容。

图2-6 DOM解析过程

图2-7 生成的DOM树示例

2.2.4.2 SAX

SAX解析XML采用事件驱动的方式。虽然并不是W3C的标准，但它的API是公认的，很多解析器都是基于它的。与DOM比较而言，SAX是一种轻量级的方法。当SAX解析器读取文档的时候会引发很多事件，这些事件会交给对应的时间处理者（event handlers）。三种基本的事件：DTDHander访问XML的DTD内容；ErrorHander解析错误；ContentHandler访问文档的内容。

图2-8 SAX解析过程

SAX模型内存消耗小，因为整个文档无需一次加载到内存中，这使SAX解析器可以解析大于系统内存的文档。另外，无需像DOM那样为所有节点创建对象，开发人员可以根据需

13

要创建自己的XML对象模型。

2.2.4.3 StAX

StAX在完美地体现XML“拉”式解析器的卓越性能和低内存，并且突破了该类解析器在功能上的有限性。与SAX一样，StAX也是基于时间流驱动的，具有类似于流媒体的优点：分析能够立即开始，而不是等待所有的数据被处理，而且由于应用程序只是在读取数据时检查数据，文档的读入过程和解析过程同时进行，所以不需要将数据存储在内存中。

StAX只解析应用程序所需要的时间流发送给应用程序，减少了向应用程序发送一些不必要的时间反馈

图2-9 StAX解析过程

2.2.4.4 三种解析技术的比较

三种技术各有各的优缺点，现将他们的优点、局限和使用地方列表如下：

图2-10 XML Parsing Techniques at a Glance（XML解析技术一览）

14

2.3 空间数据库技术概述

空间数据库是以空间数据为研究对象，在实现对空间数据的存储和操作的基础上进行空间分析和应用。空间数据库在空间信息系统中占有十分重要的地位，其投资占整个系统建设的70％甚至更多。因此，空间数据库的建设是空间信息系统建设中的一个关键问题，同时也是一项费时费力的基础性工作。在一个完整的空间数据库中，每个空间对象是由反映其几何特征的“空间数据”和非几何特征的“属性数据”表示。空间数据和属性数据是两种异质数据，同时维护两种异质数据是空间数据库区别于其他数据库的典型特征。

空间数据库在地理信息系统中得到了大量的运用，但是地理信息系统技术在取得巨大发展的同时，其孤立性、封闭性的缺陷越来越不适合现代信息社会的要求，开放式地理信息系统（OpenGIS）规范和互操作技术的提出，不仅为数据共享提供了崭新的思路，而且将GIS带入了开放的时代，从而使得各个系统间实现不同类型地理数据和地理处理方法的透明访问成为可能。

本小节的内容就围绕着OpenGIS展开。 2.3.1 OpenGIS简介

OpenGIS(Open Geo data Interoperation Specification，OGIS-开放的地理数据互操作规范)由美国OGC(OpenGIS协会，OpenGIS Consortium)提出。OGC是一个非赢利性组织，目的是促进采用新的技术和商业方式来提高地理信息处理的互操作性(Interoperability)，OGC会员主要包括GIS相关的计算机硬件和软件制造商（包括ESRI、Intergraph、MapInfo等知名GIS软件开发商），数据生产商以及一些高等院校，政府部门等，其技术委员会负责具体标准的制定工作。

OpenGIS的目标是，制定一个规范，使得应用系统开发者可以在单一的环境和单一的工作流中，使用分布于网上的任何地理数据和地理处理。它致力于消除地理信息应用（如地理信息系统，遥感，土地信息系统，自动制图/设施管理(AM/FM)系统）之间以及地理应用与其它信息技术应用之间的藩篱，建立一个无“边界”的、分布的、基于构件的地理数据互操作环境，与传统的地理信息处理技术相比，基于该规范的GIS软件将具有很好的可扩展性、可升级性、可移植性、开放性、互操作性和易用性。

15

图2-11 OpenGIS结构图

OpenGIS定义了一组基于数据的服务，而数据的基础是要素（Feature）。所谓要素简单地说就是一个独立的对象，在地图中可能表现为一个多边形建筑物，在数据库中即一个独立的条目。要素具有两个必要的组成部分，几何信息和属性信息。OpenGIS将几何信息分为点、边缘、面和几何集合四种：其中我们熟悉的线（LineString）属于边缘的一个子类，而多边形（Polygon）是面的一个子类。也就是说OpenGIS定义的几何类型并不仅仅是我们常见的点、线、多边形三种，它提供了更复杂更详细的定义，增强了未来的可扩展性。另外，几何类型的设计中采用了组合模式（Composite），将几何集合（GeometryCollection）也定义为一种几何类型，类似地，要素集合（FeatureCollection）也是一种要素。属性信息没有做太大的限制，可以在实际应用中结合具体的实现进行设置。

相同的几何类型、属性类型的组合成为要素类型（FeatureType），要素类型相同的要素可以被存放在一个数据源中。而一个数据源只能拥有一个要素类型。因此，可以用要素类型来描述一组属性相似的要素。在面向对象的模型中，完全可以把要素类型理解为一个类，而要素则是类的实例。

基类Geometry拥有Point(点), Curve(曲线), Surface(面)和GeometryCollection(集合图元)。每一个几何对象都与一个空间参照系相互关联，几何对象所定义的坐标在空间参照系得到反映。类关系图如图2-12所示：

16

图2-12 Geometry 类关系图

Geometry是OpenGIS几何模型层次关系的根类，Geometry是一个抽象(不能实例化)类。其子类实例化可得到空间参照系中的0,1,2维几何对象。

在该层次关系中的所有可实例化类这样定义可以使在系统中是拓扑相关的(例如，所有几何对象定义都包括他们的边界)。

2.3.2 MySQL中对OpenGIS的支持

MySQL是开源数据库的大鳄，从MySQL4.0开始加入了Spatial扩展功能，实现了OpenGIS规定的几何数据类型，在SQL中的简单空间运算。但是从4.0之后到现在，MySQL的Spatial部分一直没有继续的更新和增强。加上早先MySQL在SQL上对空间运算支持的不完善（只支持基于最小外接矩形的关系判断），所以MySQL是开源数据源中一个不太让人满意的选择。不过由于MySQL在小型项目上的广泛引用，在一些情况下也是可以以MySQL为数据源的。

MySQL对OpenGIS的支持主要表现在支持空间数据的数据类型，以及用于创建和检索空间值的函数上。

2.3.2.1 MySQL空间数据类型

MySQL具有与OpenGIS类对应的数据类型。某些类型只能保存单个几何值：

GEOMETRY 、POINT、LINESTRING 、POLYGON 。GEOMETRY能够保存任何类型的几何值。其他的单值类型POINT、LINESTRING以及POLYGON只能保存特定几何类型的值。

17

其他数据类型能保存多个值：MULTIPOINT、MULTILINESTRING 、MULTIPOLYGON 、GEOMETRYCOLLECTION 。GEOMETRYCOLLECTION能保存任意类型的对象集合。对于其他集合类型，MULTIPOINT、MULTILINESTRING、MULTIPOLYGON和GEOMETRYCOLLECTION，仅限于具有特定几何类型的集合成员。

2.3.2.2 MySQL创建几何值的函数：

? GeometryCollection(g1,g2,...)构造WKB GeometryCollection。如果任何参量不是构造良好的几何对象WKB表达式，返回值为NULL。

? LineString(pt1,pt2,...)从多个WKB Point参量构造WKB LineString值。如果任何参量不是WKB Point，返回值为NULL。如果Point参量的数目小于2，返回值为NULL。 ? MultiLineString(ls1,ls2,...)使用WKB LineString参量构造WKB MultiLineString值。如果任何参量不是WKB LineString，返回值为NULL。

? MultiPoint(pt1,pt2,...)使用WKB Point参量构造WKB MultiPoint值。如果任何参量不是WKB Point，返回值为NULL。

? MultiPolygon(poly1,poly2,...)从一组WKB Polygon参量构造WKB MultiPolygon值。如果任何参量不是WKB Polygon，返回值为NULL。 ? Point(x,y)使用其坐标构造WKB Point。

? Polygon(ls1,ls2,...)从多个WKB LineString参量构造WKB Polygon值。如果任何参量未表示为LinearRing的WKB形式（即，非封闭和简单LineString），返回值为NULL。 2.3.2.3 Geometry格式转换函数

? AsBinary(g)将采用内部几何格式的值转换为其WKB表示，并返回二进制结果。 ? AsText(g)将采用内部几何格式的值转换为其WKT表示，并返回字符串结果。 ? GeomFromText(wkt[,srid])将字符串值从其WKT表示转换为内部几何格式，并返回结果。

? GeomFromWKB(wkb[,srid])将二进制值从其WKB表示转换为内部几何格式，并返回结果。 19.5.2.1. 通用几何函数

? Dimension(g) 返回几何值g的固有维数。结果可以是-1、0、1或2。

? Envelope(g)返回几何值g的最小边界矩形（MBR）。结果以Polygon值的形式返

18

回。

? 多边形（polygon）是由边界框的顶点定义的：POLYGON((MINX MINY, MAXX MINY, MAXX MAXY, MINX MAXY, MINX MINY))

? GeometryType(g)以字符串形式返回几何类型的名称，几何实例g是几何类型的成员。该名称与可实例化几何子类之一对应。

? SRID(g)返回指明了几何值g的空间参考系统ID的整数。 2.3.2.4 Point函数

? X(p)以双精度数值返回点p的X坐标值。 ? Y(p)以双精度数值返回点p的Y坐标值。 2.3.2.5 LineString函数

? EndPoint(ls)返回LineString值1s的最后一个点的Point。

? GLength(ls)以双精度数值返回LineString值1s在相关的空间参考系中的长度。 ? NumPoints(ls)返回LineString值1s中的点数。

? PointN(ls,n)返回LineString值1s中的第n个点。点编号从1开始。 ? StartPoint(ls)返回LineString值1s的第一个点的Point。 2.3.2.6 MultiLineString函数

? GLength(mls)以双精度数值形式返回MultiLineString值m1s的长度。mls的长度等于其元素的长度之和。

? IsClosed(mls)如果MultiLineString值m1s是封闭的（即StartPoint()和EndPoint()值对m1s中的每个LineString是相同的）返回1。如果mls是非封闭的，返回0，如果它是NULL，返回-1。 2.3.2.7 Polygon函数

? Area(poly)以双精度数值形式返回Polygon值poly的面积，根据在其空间参考系中的测量值。

? ExteriorRing(poly)以LineString形式返回Polygon值poly的外环。

? InteriorRingN(poly,n)以LineString形式返回Polygon值poly的第n个内环。环编号从1开始。

? NumInteriorRings(poly)返回Polygon值poly的内环的数目。

19

2.3.2.8 MultiPolygon函数

? Area(mpoly)以双精度数值形式返回MultiPolygon值mpoly的面积，根据在其空间参考系中的测量结果。 2.3.2.9 GeometryCollection函数

? GeometryN(gc,n)返回GeometryCollection值gc中第n个几何对象。几何对象的编号从1开始。

? NumGeometries(gc)返回GeometryCollection值gc中几何对象的数目。 2.3.2.10 关于几何最小边界矩形（MBR）的关系

MySQL提供了一些可测试两个几何对象g1和g2最小边界矩形之间关系的函数。它们包括：

? MBRContains(g1,g2)返回1或0以指明g1的最小边界矩形是否包含g2的最小边界矩形。

? MBRDisjoint(g1,g2)返回1或0以指明两个几何变量g1和g2的最小边界矩形是否不相交。

? MBREqual(g1,g2)返回1或0以指明两个几何变量g1和g2的最小边界矩形是否相同。

? MBRIntersects(g1,g2)返回1或0以指明两个几何变量g1和g2的最小边界矩形是否相交。

? MBROverlaps(g1,g2)返回1或0以指明两个几何变量g1和g2的最小边界矩形是否交迭。

? MBRTouches(g1,g2)返回1或0以指明两个几何变量g1和g2的最小边界矩形是否接触。

? MBRWithin(g1,g2)返回1或0以指明g1的最小边界矩形是否位于g2的最小边界矩形内。

2.4 相关设计模式概述

2.4.1 设计模式的发展历史

模式的核心思想是总结和积累前人成功的设计经验，通过对这些经验的学习使得人们在面对新的设计问题时不用一切都从零开始，而是尽量套用己有的模式以提高生产效率。模式

20

体现了复用的思想。

模式的研究起源于20世纪70年代建筑工程设计大师ChristopherAlexander，他发表了很多关于城市规划和建筑设计的著作，其中明确提出了模式概念。发人员的青睐；进入90年代，面向对象的重点已经从语言转移到设计方法学方面，尽管还不成熟，但陆续提出了一些面向对象的开发方法和设计技术。随之面向对象设计模式才初露端倪。1995年由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides四人合著的《设计模式——可复用面向对象软件的基础》（简称GoF设计模式）书出版，他们对大量项目中的可重用思想进行了收集、分析并加以概括整理，最终形成了23个经典模式。GoF的“设计模式”是第一次将设计模式提升到理论高度，并将之规范化，本书提出了23种基本设计模式，自此，在可复用面向对象软件的发展过程中，新的大量的设计模式不断出现。

2.4.2 设计模式的定义与基本要素

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。

设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。

1. 模式名称（pattern name）

一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。

2. 问题(problem)

描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。

3. 解决方案(solution)

描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，

21

而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。

4. 效果(consequences)

描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。

2.4.3 设计模式的作用

面向对象设计者在软件开发时经常遇到一些问题，比如将系统分解成对象集合，同时要考虑许多因素：封装、粒度、依赖关系、性能、复用等等，有时这些因素通常还是相互冲突的。再比如，一些Java程序员在实际开发中，很少使用到面向对象的接口或抽象类，经常以那些技术只适合大型项目为由，避开或忽略它们，其实，Java的接口和抽象类是真正体现面向对象思想的核心所在。这些类似问题的原因是，开发人员对于面向对象的理解只停留在了语言层，而没有深入到设计模式中去。

设计模式并不是一种具体“技术”，它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧，让你能够真正掌握接口或抽象类的应用，从而在原来的Java语言基础上跃进一步，更重要的是，GoF的设计模式反复向你强调一个宗旨：要让你的程序尽可能的可重用。

需要指出的是，设计模式并不保证成功。一个设计模式的描述表明该模式什么时候是可适用的，但是只有经验的积累才能更好地确保何时一个特定的设计模式能够改良一个设计。

2.4.4 Gof设计模式的简介

GoF在《Design Pattern》中总结出23种经典模式，各种设计模式在粒度和抽象层次上各有不同，对它们进行分类有助于更快的学习和使用模式，主要使用下面两条准则对模式进行分类。

依据其目的可分为：创建型（Creational）、结构型（Structural）、和行为型（Behavioral）三种。创建型模式与对象的创建有关；结构型模式处理类或对象的组合；行为型模式对类或对象怎样交互作用和怎样分配职责进行描述。

依据应用范围可分为：类模式和对象模式。指定模式主要是用于类还是用于对象。类模

22

式处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译的时候就确定下来了。对象模式处理对象间的关系，这些关系在运行时刻是可以变化的，具有动态性。

图2-13 Gof设计模式

在设计中运用到的两种设计模式：

1. 观察者模式

观察者模式(有时又被称为发布/订阅模式)是软件设计模式的一种。在此种模式中，一个目标物件管理所有相依于它的观察者物件，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实作事件处理系统。

23

图2-14 观察者模式结构图

在什么时候运用：当抽象个体有两个互相依赖的层面时。封装这些层面在单独的物件内将可允许程式设计师单独地去变更与重复使用这些物件，而不会产生两者之间交互的问题；当其中一个物件的变更会影响其他物件，却又不知道多少物件必须被同时变更时；当物件应该有能力通知其他物件，又不应该知道其他物件的实做细节时。

2. 单例模式

单例模式（Singleton），也叫单子模式，是一种常用的软件设计模式。在应用这个模式时，单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象，这样有利于我们协调系统整体的行为。比如在某个服务器程序中，该服务器的配置信息存放在一个文件中，这些配置数据由一个单例对象统一读取，然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂环境下的配置管理。

实现单例模式的思路是：一个类能返回对象一个引用(永远是同一个)和一个获得该实例的方法（必须是静态方法，通常使用getInstance这个名称）；当我们调用这个方法时，如果类持有的引用不为空就返回这个引用，如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用；同时我们还将该类的构造函数定义为私有方法，这样其他处的代码就无法通过调用该类的构造函数来实例化该类的对象，只有通过该类提供的静态方法来得到该类的唯一实例。

单例模式在多线程的应用场合下必须小心使用。如果当唯一实例尚未创建时，有两个线程同时调用创建方法，那么它们同时没有检测到唯一实例的存在，从而同时各自创建了一个实例，这样就有两个实例被构造出来，从而违反了单例模式中实例唯一的原则。 解决这个问题的办法是为指示类是否已经实例化的变量提供一个互斥锁(虽然这样会降低效率)。

24

2.5 SSH构架简介

SSH框架是采用Struts+Spring+Hibernate整合而成的，SSH是分层思想的完美诠释。为Web运用的各层都提供了良好的框架整合，最大程度降低系统各层的耦合，简化了复杂的表现和逻辑处理，提高了开发的效率，增强了系统的可扩展性和维护性。

这三个框架在Web运用中都有各自的侧重点：

Struts注重表现和逻辑耦合的降低，主要把业务逻辑层和表现层分开，并不涉及业务层与持久层的关联。

Spring主要是对业务层的层次细化，即更深层次的降低了耦合程度。它利用延时注入思想组装代码，提高系统的可扩展性和灵活性，并通过Spring AOP模块实现集中式业务处理，减少代码重用。

Hibernate主要负责Java对象和关系数据库之间的映射，其实质上是一个提供数据库服务的中间件，利用数据库以及一些配置文件如hibernate properties、XML Mapping等为应用程序提供数据持久服务。

SSH整合了三个框架各自的特点及Web应用分层思想，并为Web应用各层都提供了相应的整合策略。整合框架以Spring框架为核心，向下整合Hibernate进行持久层访问，向上整合Struts使用MVC模式控制，可以清楚划分应用的层次。同时采用依赖注入思想，极大降低了层间耦合。通过XML配置文件装配组件，使各模块之间的调用从代码中分离出来，从而降低 了系统各层的耦合度，易于维护和扩展。此整合框架已经广泛应用到相关行业中。

本章小结

本章主要介绍了项目中将要用到得几门技术：AJAX技术、XML技术、空间数据库技术、设计模式和SSH框架。就几门技术的发展历史、技术特点、工作原理和使用方法做了简要地介绍。在下一章，将就撮合系统的分析与设计做深入的探讨。其主要内容包括需求分析、技术调研数据库的设计与封装和信息撮合系统的整体设计几个部分。

25

第三章 信息撮合系统的分析及设计

本章主要是介绍系统的分析与设计，主要就系统的需求分析，并对一些即将遇到的技术难点进行技术调研，然后根据实际情况对数据库设计，最后对信息撮合系统整体设计。下面将分4小结对个主要部分进行一一阐述。

3.1 需求分析

GoogleMap拼车网系统主要分为4大块：个人信息管理、线路发布、线路搜索和撮合。如图3-1所示。本小节就撮合部分的需求进行分析。

图3-1 拼车网系统功能分类结构图

信息撮合系统主要需要实现新消息提示、用户评价、乘客申请和车主邀请几大功能，所以我们可以将系统分为以下几个模块：新消息提示、评分、乘客申请及车主邀请。具体地分析留在各个小节中展现，以下简要介绍这几个模块所要实现的功能：

? 新消息提示模块，实现用户在使用系统是当有新消息给该用户时及时地提醒他注意查收；

? 评价模块，针对车主发布的某一线路已经撮合成功了，向该成功撮合的各组员发送其它人的评价邀请，记录各评分记录；

26

? 乘客申请及车主邀请模块，针对车主或是乘客的搜索后的选择结果，对双方进行撮合，以达到成功匹配的功能。 本系统用例图如图3-2所示。

新消息提示模块<><>评价模块<>用户乘客申请及车主邀请模块图3-2 信息撮合系统用例图

3.2 技术调研

在以上分析的基础上，我们项目组进行了详细地分析，觉得实现起来的技术关键点集中在以下几个方面：新消息提醒的及时性体现、数据库存储方式的选择、消息的过程形式、前后台数据交互的形式、撮合时信息对信息的处理和线路撮合成功后的评价生成。以下就分几个小节对具体的这六个方面的问题进行分析和解决。

3.2.1 新消息提醒的及时性体现

在这个模块中主要需要实现的是对用户及时的提示有新消息。在这里主要要对用户及时的提醒，当然这样的及时也不是说要求及时到向QQ聊天中那样实时会话，这样的及时只需要有消息，客户能在3分钟之内收到。

这里有两种实现方法：一种是用户登陆以后就向服务器保持一个连接，当有新消息到达的时候，服务器主动的将消息推至客户端；方法二是客户端每隔一段时间向服务器发送一个请求，要求服务器查询看有没有新消息需要达到。

这两种方法说得通俗一些就是服务器端“推”和客户端“拉”。具体分析以后发现，服务器端“推”的方法需要时刻保持一个连接，当用户数过多时，开销比较大，对服务器的压力比较大，不利于服务器的并发处理，这样的方法也相对比较传统的，不是很AJAX；客户端

27

“拉”的方法充分地体现 “富客户端”的思想，让客户端每个隔一段时间就向服务器发送一个请求，服务器就向客户端返回相应的查询结果。由于我们对新消息的实时不是很严格，只要满足在3分钟之内能够收到。所以我们可以要求客户端每个3分钟提交一次查询申请就可以轻松地解决这一问题。

于是在我们的撮合系统中选择用“客户端拉”的方式实现新消息提示，实现也是比较简单的。伪代码如下：

function getNew(){ 向服务器发送查询请求 setTimeout(“getNew()”,30000); }

3.2.2 数据库存储类型的选择

系统数据库要求存储最基本的点和线等一些拼车时出现的地理信息。这些信息会在地图显示的时候从数据库中查询得到，然后在根据查询得到的信息在地图上面显示出来，因为根据要求我们的查询支持框选、点选等一系列操作，这样就要求我们能够在用户在地图上点一个点的时候查询出通过这个点方圆一定范围（比如说是500米）以内的所有线路的信息，框选也是一样，要求我们能够通过框的位置、大小查询出通过该区域的所有有效线路的信息。

根据需求，数据库方面要求线路存储一些经过的点，还要存储一些点的信息。小组在解决存储时可以简单的用一些常用类型来实现：存储点时，用两个Double类型的字段来记录经纬度（其它字段这里不做讨论）；存储线路时，要包括需要记录的所有点信息，这样势必要形成一个新的表来记录线与点之间的关系。

如果通过上面的方式来设计地理信息的存储，系统将面临这一下几个问题：记录线与点时间关系的表将相当冗余，在查询时增加了表之间的连接操作，在记录线路的时候在必须记录里面相邻点之间的方程（因为系统在查询是要计算该路线是不是通过以查询点为中心的区域），同时系统在查询时不得不遍历所有的线路，计算存储着的所有的方程，从数学的角度分析它们之间有没有相交。这样大大地增加了系统的开销和算法的设计难度，使得搜索部分难以按要求完成。

既然这样的普通类型在设计和实现上难度很大，而且即使是实现出来效率也值得怀疑的情况下。怎么办呢？

感谢OpenGIS标准，它给我们设计出了针对地理信息系统的标准。同时感谢MySQL的Spetial Extention。它为我们提供了很多OpenGIS所规定的函数，同时把OpenGIS中规定的类

28

具体化。让系统在空间信息的存储和检索方面得到很大的优化。

于是系统存储点的时候就可以用一个Point类型的字段在记录其经纬度，存储线路时用一个LineString类型的字段来记录线路上经过的点。当系统查询符合要求的线路的时候时，可以先根据要求生成一个区域类型（Polygon）的数据，再通过MySQL中提供的函数查询获得所有和这个区域相交的线路。这样就通过简单的设计，和简单的实现，和比较优化的性能实现了需求。

3.2.3 消息表的设计

经过分析发现，用户在消息方面需要接受3中类型的消息：发给车主的消息、发给乘客的消息和撮合成功时发给所有成员的评价消息。

经过这样的分析，发现可以用3个表分别记录这些消息，因为它们需要显示的消息的内容上相差很大。但是这样就多了很多的表间关系，我们查看新消息的时候就需要同时查询这些表，并且在返回信息时，也要用不同的格式来存储。这样在后台数据生成的时候复杂度也相对增加。

既然有这么多的缺点是不是能找到一种更加简单的方法来实现？这使我们想到了就用一张表，在表中设计了一个type字段，来记录消息的类型。用了一个content字段来记录消息的内容，值得指出的是这个content字段不是随便存储的而是按照一定的格式存储进去的，因为我们在前台要根据type来确定解析content的方法，将解析后的结果正确的显示出来。当然这样做有优点也有缺点，但权衡利弊觉得用这样的设计方法还是比较不错。

一张表可以很容易的对它进行扩展，也许随着需求的变更，那天需要增加一种消息，可以把消息的type设置的不同，再把content按照该新消息的要求填入即可，没有必要想早期的想法那样去增加一张表。这样设计使得本系统课扩展性更好，使用更加灵活，后台的压力也会小一些。同时也增加了前台解析的难度，一个比较大的缺点是数据的冗余相对较大。

3.2.4 前后台新消息的交互数据

在撮合系统中，前后台的交互相当活跃。但是大量的数据交互都只涉及到极个别参数传递，同时也都是在js中通过AJAX技术实现的。所以我们不用花过多的时间去提取Form中的内容，也不用花大把的时间去解决后台的XML解析。唯一需要通过生成XML文件传输的也只有服务器向客户端传递的新消息。我们只用根据用户的编号获取用户的未读消息，将这样的一条条消息写入到XML中，向客户端发过去就完成了生成和发送部分。解析部分在客户端完成。

29

3.2.5 撮合时信息的处理

在客户端处理新消息的XML：通过DOM解析技术解析该XML，获取所有消息，将他们记录如一个个的Element，遍历这些Element，获取每个Element的中type元素的值，根据这些值的不同，通过不同的方法来解析content，从而生成记录不同消息记录的HTML DOM的Element，用这些Element重构HTML的DOM树。这样就大体的实现了客户端对XML的解析和HTML DOM树的重构。具体实现的时候需要解决浏览器兼容问题。

用户回馈评价结果：获取被评对象在该线路上的评分，重计算该评分，获取用户的总评分，加上上面的重计算的评分差，更新数据库。

用户给服务器发送撮合消息：这里系统使用到了单例模式和观察者模式来设计，根据提交的数据，如果状态是1或是2的话，表示车主和乘客的撮合记录还不存在，这样系统应该生成一条撮合记录，同时想对方按前面所说的格式添加一条新消息，在设置对方的消息数。如果是其它数字的话应该读取数据库中的该条撮合记录更改其状态，同时向上面一样对对方进行设置。

3.2.6 线路撮合成功后的评价生成

车主如果觉得线路的撮合完成了，就可以点击线路撮合成功。然后后台就根据传递过来的线路编号查询这条线路上所有撮合成功的成员。遍历这些成员，向每个人发送一跳待评价消息，消息的内容生成过程如下：获取路线信息写入相应的字段，遍历撮合成功成员，除掉自己以外的所有成员编号记录入content字段，插入数据库。

3.3 数据库的设计与封装

本节主要介绍数据库表的设计，我们可以将数据库中的表大致的为用户相关、线路相关、消息相关和撮合相关四类。以下的内容将围绕着这四类表的设计展开，用一小节的来就数据库的整体设计做一个总结。

3.3.1 用户相关表的设计

1. 用户信息表（user_information）：

? ui_id，varchar类型，长度50，用户本站ID（主键），本站注册用户的本站ID与

其登陆ID一致；

? user_name，varchar类型，长度20，姓名；

30

? ui_sex，varchar类型，长度6，性别； ? ui_birthday，date类型，出生年月； ? ui_city，varchar类型，所在城市； ? ui_phone，varchar类型，电话； ? ui_email，varchar类型，邮箱； ? ui_remark，varchar类型，个人说明；

? ui_score，integer类型，总积分（等级可按积分计算出来）。积分与用户登陆次数、成功撮合次数、用户评价有关；

? ui_sharing_num，integer类型，新消息的数量。

2. 用户权限表（user_authentication）：

? ua_id，varchar类型，长度50，用户登陆id（主键）

? ua_is_openid，Boolean类型，长度1，是否是openid用户，1表示是、0表示不是； ? ua_password，varchar类型，长度20，登陆密码，当ua_is_openid为1时为null、为0时此项是not null的；

? ua_native_ui_id，varchar类型，长度50，用户本站ID（主键）。 3.3.2 线路相关表的设计 1. 地标表（point）：

? p_id，integer类型，长度10，地点id（主键）； ? p_name，varchar类型，长度50，地点名称；

? p_point，POINT类型，长度10，点（空间数据类型，包括坐标信息）

2. 线路信息表（router_information）：

? ri_id，integer类型，长度10，线路信息id（主键）； ? ri_start_p_id，integer类型，长度10，起点id（外键）； ? ri_end_p_id，integer类型，长度10，终点id（外键）；

? ri_route，LineString类型，xianlu（空间数据类型，包括线路上所有的点信息）； ? ri_publish_ui_id，varchar类型，长度50，发布者用户id（外键）；

? ri_publish_is_owner，Boolean类型，长度1，发布者是不是车主，是则为1、不是则为0；

? ri_publish_time，DATETIME类型，发布线路的时间； ? ri_leave_time，DATETIME类型，出发时间；

31

? ri_arrival_time，DATETIME类型，到达时间； ? ri_type_st_id，拼车类型id（外键）；

? ri_status，varchar类型，长度10，线路状态：发布中，已结束（乘客撮合后即为已结束，车主停止加人后为已结束）；

? ri_request_rr_id，integer类型，长度10，拼车要求id（外键）；

3. 线路要求表（route_request）：

? rr_id，integer类型，长度10，拼车要求id（主键）； ? rr_passager_num，integer类型，长度2，乘客数量； ? rr_sex，varchar，长度6，性别限制；

? rr_people_only，Boolean类型，长度1，是否只载人，1为是，0为不是；? rr_driver_age，integer类型，长度3，司机驾龄要求； ? rr_other，varchar类型，长度200，其他要求。

4. 拼车类型（sharing_type）：

? st_id，integer类型，长度10，拼车类型id（主键）；

? st_type，varchar类型，长度20，拼车类型：上下班、旅游、临时等。 3.3.3 消息相关表的设计 1. 消息表（message）：

? m_id，integer类型，长度10，站内短消息id（主键）； ? m_form_ui_id，varchar类型，长度50，来自用户id（外键）； ? m_to_ui_id，varchar类型，长度50，目标用户id（外键）； ? m_type，integer类型，长度4，消息的类型； ? m_content，varchar类型，长度200，消息的内容； ? m_send_time，DATATIME类型，发送时间；

? m_has_read，Boolean类型，消息是否已阅读，1为已阅读、0为未读； 3.3.4 撮合相关表的设计 1. 撮合记录表（match_record）：

? mr_id，integer类型，长度10，撮合记录id（主键）； ? mr_ri_id，integer类型，长度10，撮合线路id（外键）。 2. 撮合乘客记录表（match_passenger）：

32

本文来源：https://www.bwwdw.com/article/2xa3.html