郑州公交查询系统

郑州公交查询系统

————————————————————————————————作者：————————————————————————————————日期：

郑州市公交查询系统

一.度地本系统用到的主要技术

采用java编程语言，初步打算运用EOS开发平台，数据库采用Oracle,会用到百图。

二．系统实现的主要功能

输入起点和终点，能够显示所乘公交车次（主要包括最短路径和换乘次数最少路径），百度地图上会显示路

线。

三．本系统的难点

查询最短路径的时候，用到的算法比较难（通过图来实现）；在地图上插入站点比较难（通过API插件）；数据量比较大，数据量的搜集比较难（通过网路搜索

和实地考察）。

四．本系统的亮点

1.采用百度地图，把站点插入地图中，查询的时候可

以直接在地图上显示路线。

2.能够查找出最短路径。

五．系统简介

页面主要有两个窗口，一个显示地图，一个显示车次。把站点插入百度地图，输入起点和终点，通过调用数据库查找出最短路径，在地图上显示路线，在车次窗

口中显示换乘的车次。

Public transport query system

EOS开发平台和框架

现在我天天都离不开普元EOS，我的工作就是用它来开发，相信很多朋友都用过或者听说过这个中间件和开发平台了。说实话，当初我是极度地不接受这个“东西”的。但出于工作，

我慢慢接受了这个框架。

比起Struts,Spring,Hibernate等开源框架，EOS做得更彻底，走得更远了。它有几个特

点是别的框架所没有的。

1、一个开源并且成熟的用户管理系统框架（用户管理系统是大多数应用所必须的）；

2、开发环境是eclipse二次开发（我觉得是eclipse的插件）过的，已经封装了许多“构件”，以构件为单位的编程思想贯穿其中，提高了程序的复用程度；并且能够在开发环

境中

直接拖拽构件，构件以图元的形式显示，调试方便（是不是从.NET学来的？）

3、采用“数据总线”的思想，应用各部分都共享数据总线上的数据，而不直接传递对

象；

4、对工作流开发很好的支持；

“面向构件”和“Web服务”和以上几点的确能够使EOS成为一个出色的中间件和开发平台，使工作流应用（例如OA）快速开发，不过EOS也有它的不足的地方，作为程序

员更应该客观地去看待这个“工具”。

当初开始接触EOS，感觉很不习惯，因为一些新的思想必须去接受，例如“数据总线”，“XPath存取路径”等，而且感觉自己作为程序员在使用框架的时候成就感少了，呵呵。因为什么都是现成的构件或者是半成品，我只拿过来用，后来想想，前人已经做好了轮子，何

必重复去做呢？心理有些平衡了。

现在发觉EOS有几个缺点，不知道大家认同否

1、用XPath存取数据，面向对象能力减弱。因为在数据总线上只保留数据，没有方法，

而众所周知对象是数据和方法的集合。

2、EOS的所谓MVC架构其实并不彻底，架构比较散。MVC虽然不是死的，也不一定要完全遵照MVC模式才是好的应用，但我觉得Struts在应用MVC上是成功的。而EOS 充其量只不过是多个小MVC拼凑在一起。以JSP做viewer，展现逻辑作controller，业务逻辑作model，对比在struts中只有一个单一的controller ActionServlet，我觉得后者更好。

3、EOS不是开源框架，如果应用出了什么问题，而调试时发现是框架出了问题，你只

好去找普元了，呵呵

这是我的一些看法，你呢？不妨说说啊。如果看了我的blog想了解EOS的话，那真是我的罪过了，我不是想卖广告的，到google或baidu上搜一下，一大筐，自己慢慢看吧～

普元EOS开发平台培训总结

（本文是某软件企业的技术负责人在接受普元EOS平台3.0版本的培训之后总结的心得体会。目前普元EOS产品的最新版本是5.0，作者提出的“5大缺点”如今是否仍然存在，尚

且是一个值得思考的问题。）

一EOS开发平台的功能

普元EOS是一个快速开发平台。在这个平台的基础上，可以通过既有的一些构件的功

能，来订制新的系统。

EOS专业版附带了权限和公共两个构件库，可选构件包括工作流，管理等部分。通过默认的构件库，能够轻松的调用并订制新的功能。

EOS提供一个Studio开发环境，订制过程完全图像化，可以用拖拉拽的方式实现。

对于一个全新的业务系统的开发，开发人员可以通过订制“表现自动机”，“业务自动机”

等构建整个系统。系统会自动生成相应的代码并提交到服务器。

EOS提供一个称为数据字典的数据库映射工具，将数据库表映射成某个命名的实体对

象。系统中调用命名的对象来访问数据库。

EOS提供一个JSP生成器，自动根据某个实体来生成相应的CRUD模版操作界面。

EOS支持多种应用服务器。支持部署在分布式系统上。

二EOS开发平台的优势

1 能够很快的开发出原形产品

在了解了业务需求的情况下，几个熟悉EOS的开发人员可以很快地开发出产品原形。

这适于对陌生领域的竞投标等采用。

2 学习曲线较J2EE低

EOS的一些复杂技术对开发人员透明，开发人员不许要了解过多的EJB，应用服务器等使用，只要会操作EOS的各种工具，就可以开发和部署。只需要关注业务。

3 对客户的需求更改应变能力强

整个开发都是基于图形化的流程界面，很少涉及程序代码，如果一旦客户的需求变更，只需要更新图形并重新生成代码。其他修改比较少。

4构件包可以不断积累

EOS提供了一些基本包，大量的功能都已经封装好。同时，在不同领域的实施中，还会产生该领域特色的构件包，可以积累以供将来使用。

三EOS开发平台的缺点

1 EOS构件没有统一标准

EOS的构件还没有一个统一的标准。这样就对后续开发和扩展产生了很大的影响。今后所有的产品都牢牢的绑定在EOS平台，移植性很差，完全失去了J2EE的灵活性。

2 EOS的一些概念定义含糊

例如动态EJB，数据字典，构件等，并没有给出一个确定的定义。理解起来可能存在一定困难或偏差。而实际上，动态EJB和数据字典都是在炒作概念，并没有新意。

3 EOS会导致公司技术积累下降

EOS的高度透明性同样带来了技术水平的降低。程序员无法掌握核心技术，这样一旦

发生意外，很难靠自己解决。

4 EOS无法兼容旧有产品

EOS的移植性很差，旧有的产品完全无法移植到EOS平台上。

5 EOS的工具还存在一定的差距

它的工具易用性、成熟性等方面尚存在一定的差距。例如，各种工具尚未整合到同一个

操作界面下等。

四对EOS的个人看法

通过2天的培训，对EOS有了大致了解。可以认为，EOS是一个比较稳定的快速开发平台。然而，其中的一些概念或方法，都存在着较大的风险。

首先是整个EOS这个软件的思路，它定位于一种图形快速开发平台，通过对业务建模而生成最终代码。而国际上的标准是MDA（Model Driven Architecture）。MDA发展刚起步，它的核心是MOF或元数据，并且是OMG的标准。

反观EOS，它仅仅是通过订制流程图来定义业务，一没有一个全局的架构或概况设计，二没有对业务领域的建模。如果拿过去面向过程和面向对象来比较的话正合适，EOS就是面向过程的设计。然而，它的成品是面向对象的语言Java的代码，用面向过程的方式来写面向对象的Java代码，这就是它移植性差的原因。

其次，所谓构件。照我的理解，构件，就是能够反复使用的一套业务功能或模型，其重用范围应该是整套功能而不是某个类，例如订单系统，可能包含多个类，但复用是复用整个