1.5.2 spring框架介绍
Spring是用于简化企业级JAVA程序开发的分层开源框架
Spring框架技术发展自2000年,它是 Rod Johnson 在一些成功的商业项目中应用的一种全新框架。在 2002 年,Rod Johnson 出版了《Expert One-on-One J2EE Design and Development》一 书中,提供了随书一个初步的开发框架nterface21 开发包,书中阐述的编程思想的方法在interface21中得到了具体实现。后来, Rod Johnson进行了进一步的改造升级和扩充的interface21功能。使之成为一个更加成熟开放全面的框架。到2003 年 2 月 Spring 框架正式成为一个开源项目,并发布于 SourceForge 中。
Spring框架为企业级的软件的开发，提供了一站式的解决方案，对大量的企业级服务提供了再次的封装，去除重复的代码 ，Spring很容易的集成其它的子框架，集成Struts1、WebWork、Hibernate等其它框架。
1、在没有spring框架的采用J2EE开发经常性存在的问题：
1）EJB软件难编写，难测试 2）EntityBean作为持久化方案，性能比较低下，O/R Mapping支持不够，不能脱离容器。 3）设计困难 4）侵入式方案，EJB要使用特定的接口 2、使用了spring框架之后J2EE开发的优点
Spring是一个开源框架，由Rod Johnson创建。它视为了解决企业应用开发的复杂性而创建的。Spring使用基本的JavaBean来完成以前只能由EJB完成的事情。然 而，Spring的用途不仅限于服务器端的开发。任何Java应用都可以从Sprin框架中的松耦合和可测试性的特征使任何一个JAVA应用都能从中受益颇多。 1） 轻量－从大小和开销两个方面而言Spring都是轻量的。Spring应用中的对象不依赖于Spring的特定类。
2） 控制反转－Spring通过IoC技术促进了松耦合。当应用其的时候，一个对象依赖的其他对象会通过被 动的方式传递进来，而不是这个对象自己创建或者查找依赖对象。可以理解成为IoC和JNDI相反。 框架－Spring可以将简单的组建配置、组合成为复杂的应用。不过从某种意义上来看，这样增加了开发的复杂性，相当于手写配置文件 Spring的使命（Mission Statement）： J2EE应该更加容易使用
面向对象的设计比任何实现技术都重要
面向接口编程，而不是针对类编程。Spring将使用接口的复杂度降低到零。 代码应该易于测试［这个使命其实是和敏捷中的测试驱动开发方法有相照应的地方］ JavaBean提供了应用程序配置的最好方法 核心容器：
这是Spring框架里最基础的部分，它提供了依赖注入（Dependency Injection）特征来实现容器对Bean的管理。
应用上下文（Context）模块：
核心模块的BeanFactory使Spring成为一个容器，而上下文模块使它成为一个框架。 另外，这
11 / 54
个模块提供了许多企业服务。也包括了对模板框架例如Velocity和FreeMarker集成的支持。 Spring的AOP模块： JDBC抽象和DAO模块： Spring的Web模块： Spring的MVC框架：
1.5.3 ibatis框架介绍
iBatis 是apache 的一个开源项目，一个O/R Mapping 解决方案，iBatis 最大的特点就是小巧，上手很快。 相对于Hibernate等“一站式”ORM(对象关系映射)框架，Ibatis是一种“半自动化”的ORM框架实现。Ibatis框架只重视O/R模块的内容，淡化M(mapping)这一模块部分的概念。因为它将对于SQL语句的操作权，最终交还给了程序员。
在Hibernate框架中，程序员不需要了解复杂的SQL语句，因为Hibernate框架机制中会自动根据POJO的映射关系，自动的为程序员生成相对应的SQL语句，最后通过JDBC技术来完成对数据库的数据操作，实现数据的持久化。程序员在程序中只需要操作POJO模块就能实现目的。而IBATIS框架必须需要程序员自己手写每一条SQL语句，把对数据库的操作权限交给程序员自己本身。为什么要舍弃简单的hibernate使用半自动的ibatis的原因是Hibernate框架提供的这种所谓的一站式解决并不能解决所有日常程序开发中遇到的所有问题。当遇到一些需要保密行业的系统开发项目时候，一些行业并不会公开数据库中的数据和表的结构。只会提供SQL查询语句给开发者使用，这个时候使用POJO自动映射数据库显然不行。 还有一些因为开发规范的需要，在业务逻辑部分进行对数据库的操作 必须要求通过存储过程进行操作的时候，这个时候使用POJO自动映射数据库显然不行。还有对系统数据处理量巨大，对性能要求非常高用hibernate也是行不通的。
ibatis语言最大的特点还是因为ibatis语言入门相当简单，适合初学者。而且ibatis数据库又能提供灵活的数据库解决方案和满足你程序对数据库的要求，而且在数据库查询的时候提供了自动绑定对象的模块。当然iBATIS的缺点是框架还不够成熟，目前来看虽然简化了大量绑定数据库的数据，但是整个SQL语句需要程序员自己来写，工作量相对来说较大。但当系统进行再次开发和升级时, iBATIS的灵活性比Hibernate将具有更大的优势。还有就是系统需要处理大量数据，对服务器性能和响应时间要求极为严格，这样必须通过优化SQL语句才能达到系统设计目标。这个时候，iBATIS的半自动将给程序员更大的空间，有更好的可控性和表现。运行效率在不考虑 cache 的情况下，iBatis 应该会比hibernate 快一些或者很多
12 / 54
第二章 系统分析
2.1 系统可行性分析
2.1.1 经济可行性分析
海铁联运信息平台是在充分分析了用户需求和市场需求之后建设的平台，在目前国内港口主要70%货物通过海铁联运运输方式的基础上，海铁信息平台已经基本成型，没有市场空间的前提下，抓住国内海陆运输的信息真空，建设海陆联运信息平台具有巨大市场空间和潜力。海陆联运信息平台是一个拥有固定用户定位于专业性信息共享平台的网站，网站用户访问的浏览量不会很大，网站实现主要以功能为主，不需要复杂花哨的界面设计，网站对服务器的开销相对也不会很大，网站的开发生命周期和开发风险相对较小。平台建成后易于维护和扩展，维护成本和开销相对较小，在网站运行之后仅为网站配备一名管理人员和一名客服来实现网站的持续性运转。
海铁联运信息平台为所有船代角色实现网上动态发布货源等待车队报价的功能。这样避免传统作业船代花大量人力成本寻找车辆运输货物和运费的不可控性，海陆联运为所有车队提供了一次公平的网上竞价平台 车队可以看到所有货物信息 公平竞争 避免暗箱操作，使更多的车队分享利润。同时网站提供双发的信誉评价增加了解，减少双方的不信任性。系统建成后可以货主，车队 箱主，货代 船代等角色中免费推广使用，不一次性收取系统开发，在系统信息共享电子交互数据能够为用户节约人工成本，提高各个角色的利润之后，增加用户黏性之后，从用户的每一次成交量中收取手续费，实现系统可持续性的盈利目的和后期系统的维护成本
2.1.2技术可行性分析
在信息化高度发达的今天，国内大多数企业，政府机关，供货商，销售商都拥有自己的网站，网站设计的技术已经非常发达，系统分层框架已经非常成熟，成功的案例很多。在网站前台设计的HTML，CSS，JAVASCRIPT技术可以轻松的查询文档找到解决办法和设计方案。同时系统选用的JAVA平台作为目前开发应用最广泛的语言，在遇到问题的时候可以得到大量的技术支持。数据库选择方面选择是大学专业课程 也是目前最为流行的oracle数据库。在编写SQL语言使用了著名的第三方客户端PL/SQL 整个系统开发起来非常得心应手。避免了对新技术的盲目使用和崇拜，选择了最适合自己的开发语言和平台。
2.2需求分析
需求分析是系统开发中必不可少的环节，一个系统开发的好坏，最关键的部分是看前期的对用户
13 / 54
的需求分析报告，通过需求分析了解目前网站受众需要什么样的需求，用户需要什么样的体验和服务，再进一步开发符合用户需求的系统是每一个系统成功的关键。只有在成功理解了用户的当前需求之后开发的系统才是能够收到用户欢迎和增加用户黏性的系统 进而使整个系统获得盈利。
在征询和走访一些用户和查询连云港港务资料后提炼出连云港港口和公路之间的运输现状 1连云港运输市场混杂、急需净化；小货代、小车队比较多，缺乏监管机制。
2车多货少，导致车队为找货源恶性竞争、互相拆台，造成货主对港口极度不信任，需要提升港口公平竞争、诚信的形象。
3价格不统一，许多货代在运输车队选择中，无法掌握明确的运输价格而导致企业经营成本上升、负担增加。
4各类用户（货代、车队等）之间信任度低，各类用户信息做不到共享。例如：车主为了利益避免空驶，私装货物等现象，船代、箱管、货主货代等用户希望能有所监控。 5各方费用结算存在拖欠情况，严重的长达一年费用未结清。
在深入分析连云港港口公路运输市场现状的基础上，提高车、货等信息资源的共享程度，搭建一个能够帮助物流需求方发布货源功能、物流供应方寻找货源功能，提供查询功能、选择和交易前后的信息管理功能，沟通各类用户物流运输信息服务功能、用户信誉评级功能的海陆信息平台是当前用户最需要的功能模块。
2.3 系统数据流图
数据流图是在软件开发生命周期的前期阶段开始进行设计的，在软件开发生命周期后续阶段不断的细化，修改和完善这一数据流程图。对系统开发的数据流程进行分析可以方面发现系统中存在不合理的地方和存在的问题，这样可以清晰的在信息平台的建设过程中改进和完善系统。数据流图（英文 Data Flow Digram）是描绘软件系统逻辑模型的一个图形，数据流图描绘信息和数据之间从输入到输出的过程中所经历的一系列变化。设计数据流图时舍弃这些具体功能，只要把系统中的数据流抽象出来，用来表达软件系统中数据和系统中各个功能模块的之间的关系和数据的最终流向。
数据流图中有主要有四种元素。
第一种 数据的源点 表示数据的产生的地方和最终抵达的地方。 第二种 数据流 表示动态数据的流向。
第三种 处理逻辑 表示对数据进行的逻辑操作的动作。 第四种 数据存储 表示需要存储的可持久化的数据。
14 / 54
数据流图的四种元素对应的基本图形为
源点或终点 数据流 逻辑处理 数据存储
海陆联运信息平台的数据流图
这个数据流图由货主新增货源到货源表中开始。车队通过货源表信息查找货源信息，并根据货源信息进行报价，录入报价表。货代根据报价表选择是否接受报价录入合同表 车队根据箱信息对对不同箱子配置不同车辆信息
15 / 54