2022年郑州公交查询系统 .pdf

《2022年郑州公交查询系统 .pdf》由会员分享，可在线阅读，更多相关《2022年郑州公交查询系统 .pdf（8页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、郑州公交查询系统名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 8 页 - - - - - - - - - 2 作者：日期：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 8 页 - - - - - - - - - 3 / 8 郑州市公交查询系统一. 度地本系统用到的主要技术采用 java 编程语言，初步打算运用 EOS开发平台，数据库采用 Orac

2、le,会用到百图。二 系统实现的主要功能输入起点和终点，能够显示所乘公交车次（主要包括最短路径和换乘次数最少路径） ， 百度地图上会显示路线。三 本系统的难点查询最短路径的时候，用到的算法比较难（通过图来实现） ；在地图上插入站点比较难（通过API 插件） ；数据量比较大，数据量的搜集比较难（通过网路搜索和实地考察）。四 本系统的亮点1.采用百度地图，把站点插入地图中，查询的时候可以直接在地图上显示路线。2.能够查找出最短路径。五系统简介页面主要有两个窗口， 一个显示地图， 一个显示车次。把站点插入百度地图，输入起点和终点，通过调用数据库查找出最短路径，在地图上显示路线，在车次窗口中显示换乘的

3、车次。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 8 页 - - - - - - - - - 4 / 8 Public transport query system EOS 开发平台和框架现在我天天都离不开普元EOS，我的工作就是用它来开发，相信很多朋友都用过或者听说过这个中间件和开发平台了。说实话，当初我是极度地不接受这个“东西” 的。但出于工作，我慢慢接受了这个框架。比起 Struts,Spring,Hibernate 等开源框架， EOS 做得更彻底，走得更远了

4、。它有几个特点是别的框架所没有的。1、一个开源并且成熟的用户管理系统框架（用户管理系统是大多数应用所必须的）；2、开发环境是eclipse 二次开发 （我觉得是eclipse 的插件） 过的，已经封装了许多 “构件” ，以构件为单位的编程思想贯穿其中，提高了程序的复用程度；并且能够在开发环名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 8 页 - - - - - - - - - 5 / 8 境中直接拖拽构件，构件以图元的形式显示，调试方便（是不是从.NET 学来的？）3、

5、采用“数据总线”的思想，应用各部分都共享数据总线上的数据，而不直接传递对象；4、对工作流开发很好的支持；“面向构件”和“ Web 服务”和以上几点的确能够使EOS 成为一个出色的中间件和开发平台，使工作流应用（例如OA）快速开发，不过EOS 也有它的不足的地方，作为程序员更应该客观地去看待这个“工具”。当初开始接触EOS，感觉很不习惯， 因为一些新的思想必须去接受，例如“数据总线”，“XPath 存取路径”等，而且感觉自己作为程序员在使用框架的时候成就感少了，呵呵。因为什么都是现成的构件或者是半成品，我只拿过来用，后来想想，前人已经做好了轮子，何必重复去做呢？心理有些平衡了。现在发觉 EOS

6、有几个缺点，不知道大家认同否1、用 XPath 存取数据， 面向对象能力减弱。因为在数据总线上只保留数据，没有方法，而众所周知对象是数据和方法的集合。2、EOS 的所谓 MVC 架构其实并不彻底，架构比较散。MVC 虽然不是死的，也不一定要完全遵照MVC 模式才是好的应用，但我觉得Struts 在应用 MVC 上是成功的。而EOS充其量只不过是多个小MVC 拼凑在一起。 以 JSP做 viewer，展现逻辑作controller ，业务逻辑作 model，对比在 struts 中只有一个单一的controller ActionServlet ，我觉得后者更好。3、EOS 不是开源框架，如果应用

7、出了什么问题，而调试时发现是框架出了问题，你只好去找普元了，呵呵这是我的一些看法，你呢？不妨说说啊。如果看了我的blog 想了解 EOS 的话，那真是我的罪过了，我不是想卖广告的，到google 或 baidu 上搜一下，一大筐，自己慢慢看吧普元 EOS开发平台培训总结（本文是某软件企业的技术负责人在接受普元EOS 平台 3.0 版本的培训之后总结的心得体会。目前普元EOS 产品的最新版本是5.0 ，作者提出的“ 5 大缺点”如今是否仍然存在，尚且是一个值得思考的问题。）一 EOS 开发平台的功能普元 EOS 是一个快速开发平台。在这个平台的基础上，可以通过既有的一些构件的功能，来订制新的系统

8、。EOS 专业版附带了权限和公共两个构件库，可选构件包括工作流，管理等部分。通过默认的构件库，能够轻松的调用并订制新的功能。EOS 提供一个 Studio 开发环境，订制过程完全图像化，可以用拖拉拽的方式实现。对于一个全新的业务系统的开发，开发人员可以通过订制“ 表现自动机 ” ，“ 业务自动机 ”等构建整个系统。系统会自动生成相应的代码并提交到服务器。EOS 提供一个称为数据字典的数据库映射工具，将数据库表映射成某个命名的实体对名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页

9、，共 8 页 - - - - - - - - - 6 / 8 象。系统中调用命名的对象来访问数据库。EOS 提供一个 JSP 生成器，自动根据某个实体来生成相应的CRUD 模版操作界面。EOS 支持多种应用服务器。支持部署在分布式系统上。二 EOS 开发平台的优势1 能够很快的开发出原形产品在了解了业务需求的情况下，几个熟悉EOS 的开发人员可以很快地开发出产品原形。这适于对陌生领域的竞投标等采用。2 学习曲线较J2EE低EOS 的一些复杂技术对开发人员透明，开发人员不许要了解过多的EJB ，应用服务器等使用，只要会操作EOS 的各种工具，就可以开发和部署。只需要关注业务。3 对客户的需求更改

10、应变能力强整个开发都是基于图形化的流程界面，很少涉及程序代码，如果一旦客户的需求变更，只需要更新图形并重新生成代码。其他修改比较少。4 构件包可以不断积累EOS 提供了一些基本包，大量的功能都已经封装好。同时，在不同领域的实施中，还会产生该领域特色的构件包，可以积累以供将来使用。三 EOS 开发平台的缺点1 EOS 构件没有统一标准EOS 的构件还没有一个统一的标准。这样就对后续开发和扩展产生了很大的影响。今后所有的产品都牢牢的绑定在EOS 平台，移植性很差，完全失去了J2EE 的灵活性。2 EOS的一些概念定义含糊例如动态EJB，数据字典，构件等，并没有给出一个确定的定义。理解起来可能存在一

11、定困难或偏差。而实际上，动态EJB 和数据字典都是在炒作概念，并没有新意。3 EOS 会导致公司技术积累下降EOS 的高度透明性同样带来了技术水平的降低。程序员无法掌握核心技术，这样一旦发生意外，很难靠自己解决。4 EOS 无法兼容旧有产品EOS 的移植性很差，旧有的产品完全无法移植到EOS 平台上。5 EOS 的工具还存在一定的差距它的工具易用性、成熟性等方面尚存在一定的差距。例如，各种工具尚未整合到同一个操作界面下等。四 对 EOS 的个人看法通过 2 天的培训，对EOS 有了大致了解。可以认为，EOS 是一个比较稳定的快速开发平台。然而，其中的一些概念或方法，都存在着较大的风险。首先是整

12、个EOS 这个软件的思路，它定位于一种图形快速开发平台，通过对业务建模而生成最终代码。而国际上的标准是MDA （Model Driven Architecture） 。MDA 发展刚起步，它的核心是MOF 或元数据，并且是OMG 的标准。反观 EOS，它仅仅是通过订制流程图来定义业务，一没有一个全局的架构或概况设计，二没有对业务领域的建模。如果拿过去面向过程和面向对象来比较的话正合适，EOS 就是面向过程的设计。然而，它的成品是面向对象的语言Java 的代码，用面向过程的方式来写面向对象的Java 代码，这就是它移植性差的原因。其次，所谓构件。照我的理解，构件，就是能够反复使用的一套业务功能或

13、模型，其重用范围应该是整套功能而不是某个类，例如订单系统， 可能包含多个类，但复用是复用整个名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 8 页 - - - - - - - - - 7 / 8 定单系统。 Java 中有 portlet标准，即为门户定义的标准。每个portlet可对应一套构件。只要订单系统实现portlet 标准，就可以在WEB 上任意的地方重用订单。Java 中被广泛接受的构件概念，是POJO 或 JavaBean ，即带有业务功能的领域模型。而 E

14、OS 中的构件实际上就是一个类中的函数。根据我的分析，EOS 实际上是将业务流程定义在 XML文件中，然后用固定出入口的许多函数来调用和执行流程。按照它的这种方式，复用竟然具体到函数。每个函数都是用的类似的参数，一般是 XML 文档和实体对象等。EOS 并没有给出系统接口或扩展标准，后续开发或扩展很困难，开发一个复杂的系统风险很高。标准，关系到EOS 的成败。EOS 不适合技术型的开发人员使用。大量雷同的操作和对核心技术的屏蔽会使热衷于技术的人失去兴趣。这平台对技术水平比较低，但对业务比较熟悉的技术支持人员可能会很有效。软件开发是人而不是机器的工作，因此，人的能动性在开发中起了非常重要的作用。

15、忽视了对人的培养，只能带来更高的人员流动率。EOS 不能用于对现有OA 产品的更新换代和移植。但可以用来进行新领域的竞标等方面。然而，不可忽视的是，由于EOS 扩展的困难性和核心技术的缺乏，对EOS 的依赖将不可避免。以上是我对EOS3.0 的总结。经过几天的培训，我认为EOS 实际的平台比宣传的差很多，目前仍不能用于真正的企业级开发。另一篇关于普元的blog: 普元软件公司是国内专业的中间件提供商，从国家得到了不少投资，做出来的东西也是相当的庞大。最近普元 EOS 的宣传和发展的势头都很盛。其宣传材料中屡次提到“ 软件的涅磐 “ 这一用语，这明显是一种危言耸听之举，当然这在业内也不算什么新鲜

16、的事情。按照EOS 的宣传， 以图形化的构件组装方式“ 画” 出来的软件无论从结构上、形式上还是开发过程上都堪称简捷而美的软件。这一提法倒是别开生面。图形化与简洁，与美竟然还存在着这样必然的联系，实在是一种创举。从普元公开的资料来看，EOS 的一个鲜明特征是全面基于xml 描述，即所谓的xml 数据总线。表面上看起来，xml 结构内置于系统内核中似乎很时尚，但实际上，EOS 产生的 xml描述文件中的大量条目都是EOS 自身的结构要求，而与实际业务无关，即 EOS 描述文件中的有效信息量密度很低。这是一个危险的信号。EOS 的 xml 描述本身可以看作是一种完全新的编程语言， 但这个语言似乎没

17、有什么抽象能力和组合能力，对于关联的表达能力也很弱（到处都是数字id)。如果直接手工编写，那是一件要死人的事情。只有通过集成开发环境的可视化界面，EOS 才呈现出可理解的一面。EOS 的概念与 Language Workbench 是不同的， 其中的结构似乎很难进行有效的扩展。而所谓的 xml 总线技术更加剧了这一点。xml 数据总线其实与面向过程编程类似，只是过程变成了 service，数据变成了xml 节点而已。对象与简单数据结构在结构表达上的本质差异就在于对象通过成员函数可以封装动态结构。虽然xml 节点的表达能力远远超越了普通的数据类型， 但充其量也不过是对现有数据的规整的树形表示，并

18、不具有动态计算能力（甚至是名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 8 页 - - - - - - - - - 8 / 8 最简单的lazy evaluation） 。 丧失了动态计算能力， 就意味着我们很难在系统中动态引入结构，程序中所操纵的结构都需要事前定义出来，这将极大的限制系统的可扩展性。另一方面， xml节点受限于自身格式，其描述关联的能力也要弱于java 对象结构本身。对象通过引用访问相关对象， 其隐含意义是对象处于同一地址（状态）空间中，可以非常自然的

19、保证对象的唯一性并实现同步访问。在跨越状态空间的边界时，xml 表示是有意义的，因为我们需要把所有的结构都暴露出来并加以描述(外在化）。而在状态空间内部，我们需要更加紧致有效的表述方式。在具体的实现中，EOS 暴露给程序员的xml 操纵 API 相当的原始，使用起来很繁琐。在前台展示页面中，如果不使用EOS 的界面组件， 提取数据本身就是一种不小的困难。EOS的前台展示组件与后台的结合也比较弱，后台改变之后， 缺乏有效的手段来检测并保证前后台结构的同步性。 所谓的前台构件层似乎只是提供了一些帮助函数和功能固化的组件，并没有提供什么有效的利于结构抽象和结构重组的机制。整个 EOS 的构架看起来很象是一个monster, 我很难想象它的各个部分如何才能独立的，深入的发展下去。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 8 页 - - - - - - - - -