工作，并对突发事件做出及时和准确的调整；能够确保托运人以及收货人对货物进行及时处理[5]。
从经济性上讲，该仓库管理信息系统的业务流程规范、科学，界面友好，操作环境便捷，将为企业带来更多的客户资源，树立企业的品牌形象，提升企业的经济效益[6]。
1.3论文的内容和结构
首先在绪论里，介绍仓库管理信息系统开发的背景及国内外开发应用的现状，阐明仓库管理信息系统对于企业的重要性。
其次，对实现此系统用到的技术进行简介。第一，介绍了J2EE平台。对于J2EE平台，从J2EE平台的概念及J2EE平台的体系架构两方面，进行了概述；对于MVC组件及ORM组件，则从他们的实现、工作流程及机制、优缺点及为什么要使用他们进行了阐述。第二，从软件开发模式、MVC模式概述、MVC模式在Web上的应用情况及MVC模式的好处等几方面[7]，简述了MVC模式。
再次，根据系统需求分析及功能分析，进行数据库设计及系统技术架构设计。第一，从系统概述与目标、系统功能性需求、系统非功能性需求共三方面，进行了系统的需求分析，并从系统功能模块划分以及系统流程等两方面，进行了系统功能的分析。第二，结合系统需求分析及系统功能分析，从数据库需求分析、数据表结构设计等两方面，进行了数据库设计。第四，从逻辑结构设计、技术方案实现等方面，进行系统技术架构设计。在进行系统逻辑结构设计时，从逻辑结构分析、表示层设计、控制层设计、业务逻辑层设计、持久层设计等五个方面，进行了探讨；在阐述技术方案时，从配置web.xml文件、配置mvc.xml文件、c3p0数据池的配置文件、Action的编写过程、业务逻辑编写过程、持久层设计以及视图层开发技术等七个方面，进行了介绍。
进行模块设计时，采用J2EE开发规范以及MVC框架，分为Controller（控制器）、Model（模型）、View（视图）三层[8]。其中，Controller的作用是从客户端接受请求，并且选择执行相应的业务逻辑，然后把响应结果送回到客户端；Model层实现业务逻辑；View层是应用程序中用户界面相关的部分，负责向用户显示数据，并且能接收用户的输入数据。
最后，对该仓库管理信息系统设计进行了总结，并对该仓库管理信息系统应用前景进行了展望。
论文的总体结构如下：
第一章简述论文背景以及论文的内容及意义。
第二章阐述开发该仓库管理信息系统的平台和用到的技术。
第三章内容为该仓库管理信息系统需求分析和系统总体设计，数据库设计。
第四章对该仓库管理信息系统的各个模块的实现进行了详述。
第五章对该仓库管理信息系统设计进行了总结，并对该系统应用前景进行了展望。
第二章 相关技术
2.1 J2EE平台
2.1.1 J2EE平台简介
J2EE可以说指Java在数据库信息系统上实现，数据库信息系统从早期的dBase、到Delphi/VB等C/S结构，发展到B/S（Browser浏览器/Server服务器）结构，而J2EE主要是指B/S结构的实现。
J2EE主要是为企业级开发提供了一种设计模式，sun在每个领域给了一个设计模式，象嵌入式平台的J2ME,桌面平台的J2SE。在一个规范的J2EE架构中，不同层的数据表示应该被限制在层内，而不应该扩散到其它层，这样可以降低层间的耦合性，提高J2EE架构整体的可维护性和可扩展性。比如说Web层的逻辑进行了修改，那么只需要修改FormBean的结构，而不需要触动业务层和持久层的代码修改。同样的，当数据库表进行了小的调整，那么也只需要修改持久层数据表示，而不需要触动业务层代码和Web层代码。
J2EE技术在应用时都涉及两个部分：容器部分和应用部分，Web容器也是指Jsp/Servlet容器，你如果要开发一个Web应用，无论是编译或运行，都必须要有Jsp/Servlet库或API支持（除了JDK/J2SE以外）。在许多企业级应用中，例如数据库连接、邮件服务、事务处理等都是一些通用企业需求模块，这些模块如果每次再开发中都由开发人员来完成的话，将会造成开发周期长和代码可靠性差等问题。于是许多大公司开发了自己的通用模块服务。这些服务性的软件系列统称为中间件。为了通用必须要提出规范，不然无法达到通用在上面的需求基础之上，许多公司都开发了自己的中间件，但其与用户的沟通都各有不同，从而导致用户无法将各个公司不同的中间件组装在一块为自己服务。从而产生瓶颈。于是提出标准的概念。所以说，J2EE就是基于JAVA技术的一系列标准。
2.1.2 MVC组件简介
为什么我们在J2EE开发中需要框架？
JSP、Servlet和JavaBean技术的出现给我们构建强大的企业应用系统提供了可能。在此之上，我们还需要一个规则，一个把这些技术有效的组织起来，让系统繁而不乱的规则，这就是框架。Struts应运而生，是最早的开源框架之一，而且很快成为实际标准。
在J2EE平台下，Struts是比较流行的MVC框架，但是本着DIY动手能力及探索的精神，这一次没有用到成熟的Struts来作为MVC框架，而是自己编写简单的MVC组件来解决问题[13]。
"麻雀虽小五脏俱全"，这次绝不是"重复的造轮子"的过程，吸收了前辈Struts2的优秀特性，结合了其他MVC框架：尤其是"rails"的"约定优于配置"的理念，让这个DIY的MVC组件有着小巧，简洁，方便使用的特性。
在现如今大量的MVC框架里面，xml配置文件是很重要的，特别常见的，他们定义了一个请求的URL及处理该请求的对应的Action的地址。但是，这也带来了一些问题，很多时候这些繁杂的xml配置文件会让人感到厌倦 。
于是，我尝试用其他方法来替代这个方案："利用约定来免除大量的配置文件"。先让我们来看看这个MVC组件的工作机制[15]。
在此组件中，控制器由MVCFilter及Controller来实现，视图由一组JSP文件与JSTL标签库构成。
图2-1 MVC组件结构图 此MVC组件包含了以下重要部分：
（1）视图
视图部分可以采用JSP来实现。在这些JSP文件中没有业务逻辑，也没有模型信息，只有标签，这些标签可以是标准的JSP标签或自定义的标签，如JSTL标签库。
（2）控制器
其工作流程如下--
第一步：
当用户通过视图向服务器发送请求时，请求URI会被一个Filter（servlet规范里的拦截器）拦截，这个Filter将拦截的URI进行处理，根据从mvc.xml配置文件读取的映射信息及已经定义好的约定，就可以实现从URI到Action的映射。
第二步：
控制器找到了处理该请求的Action包路径以后，运用反射实例化之，并调用execute（来自于Action接口）方法来获得返回视图的地址。最后，控制器负责转发视图资源请求。
（3）区别于Struts2的地方
在Struts2里面，用户请求是通过核心拦截器来处理及转发的。这需要一些描述用户请求路径及Action映射关系的配置信息。这些配置映射信息都存储在特定的XML文件Struts-config.xml中[16]。在该配置文件中，每一个Action的映射信息都通过一个
元素来配置。
这些配置信息在系统启动的时候，被读入内存，供Struts在运行期间使用。在内存中，每一个元素都对应一个ActionMapping类的实例。
现在，只要根据既定的约定（URI路径对应这相应的Action包路径），读取存储在mvc.xml文件里面的信息，就可以根据请求的URI映射到对应的Action包路径。从而免去了繁琐的配置文件，集中精力负责其他的设计。
这就是："约定优于配置"原则下的设计。
MVC的优缺点，可以简单总结如下：
（1）优点
衡量J2EE应用系统设计开发水平高低的标准就是：解耦性；你的应用系统各个功能是否能够彻底脱离？是否不相互依赖，也只有这样，才能体现可维护性、可拓展性的软件设计目标。为了达到这个目的，诞生各种框架概念，J2EE框架标准将一个系统划分为WEB和EJB主要部分，当然我们有时不是以这个具体技术区分，而是从设计上抽象为表现层、服务层和持久层，这三个层次从一个高度将J2EE分离开来，实现解耦目的。应用数据的表示应该被限制在相应的层内，而不扩散到其它层，这样可以降低数据在应用层之间的耦合性，提升J2EE整体架构的可维护性及可扩展性。
同时，得益于JSTL标签库的使用，抛弃了传统的jsp标签（事实上，几乎没有正规的开发会用到jsp原始的标签了），能大大提升开发效率。
约定优于配置，通过一个配置文件里面的1行信息，即可把握整个系统各部分之间的联系，同时又避免了复杂的xml配置文件。这对于后期的维护有着莫大的好处，对团队合作开发，这种优势体现得很突出。
（2）缺点
JSTL标签库的一大优势是使得jsp页面的开发更加简单，但需要一个持续学习的过程，学习成本显而易见。
比起强大的Struts2把视图资源放置在xml文件里的特性，这个组件尽可能不使用配置文件，直接把视图资源硬编码到Action里面，这样做的一个坏处是：每次要改变视图资源的时候，必修重修修改Action的代码，然后重新编译。
2.1.3 持久层组件简介
在Java中将对象自动持久化到数据库中，我们需要了解两个概念。持久化：就是对数据和程序状态的保持。大多数情况下特别是企业级开发应用时，数据持久化往往也就意味着将内存中的数据保存到磁盘上，就是把数据保存到可掉电式存储设备中供之后使用。大多数情况下特别是企业级应用，数据持久化往往也就意味着将内存中的数据保存到磁盘上加以固化，而持久化的实现过程则大多通过各种关系数据库来完成。那么持久层呢？延续思路，所谓"持久层"，也就是在系统逻辑层面上，专著于实现数据持久化的一个相对独立的领域(Domain)。持久层是负责向（或者从）一个或者多个数据存储器中存储（或者获取）数据的一组类和组件。这个层必须包括一个业务领域实体的模型（即使只是一个元数据模型）。不过这里有一个字需要特别强调，也就是所谓的"层"。对于应用系统而言，数据持久功能大多是必不可少的组成部分。之所以要独立出一个"持久层"的概念,而不是"持久模块"，"持久单元"，也就意味着，我们的系统架构中，应该有一个相对独立的逻辑层面，专著于数据持久化逻辑的实现.与系统其他部分相对而言，这个层面应该具有一个较为清晰和严格的逻辑边界。
对于一个框架，仅仅掌握它的使用方法还远没达到目的，最重要的是：你是否能够了解它的原理。基于这点，我想很有必要亲自模拟并且实现ORM（持久层的组件，也就是所谓的：对象关系映射组件）框架最基本的，也是最核心的功能。
先来看一下这个自行设计的ORM组件的简单工
上一篇：基于J2EE框架的个人博客系统项目毕业设计论文(1)(word文档)
下一篇：陕西师范大学远程教育学院毕业论文
2014-5-4
