网络购物系统论文

1、 毕 业 论 文（设计） 题 目： 网络购物服务系统 系 名 称： 专业名称： 班级名称： 学生姓名： 学号： 指导教师： 完成时间： 目 录摘要 第1章 绪论1.1网上购物系统概述 .31.2 系统开发背景.4第二章 技术概述2.1什么事JSP，JSP的特点？.52.2 JSP的特点.52.3Hibernate 技术2.3.1 Hibernate优点.62.3.2 Hibernate缺点.62.4 Spring技术2.4.1Spring技术的特点.72.4.2Spring框架图：.72.4.3 Spring Web MVC的实现 .8第三章：需求分析.253.1 用户需求.253.2 需求分

2、析和设计.263.2.1系统功能.263.3选择网上购物的原因.263.4用户选择商品配送的方式 .273.5网上交易存在的问题.27第四章：系统框架4.1系统架构图.284.2系统功能模块设计.28五系统网络数据库的建立5.1 数据源.375.1.1 创建数据库链接(Hibernate).385.1.2 操作数据库.39结束语.41致谢.43参考文献】：.43网络购物系统的设计与实现专 业:软件技术 学 号:学生姓名: 指导老师:摘 要社会在不断的进步，科技在不断的发展，人民的生活水平在不断的提高，尤其是随着网技术和计算机技术的快速发展，以及数据库技术在网络中的应用，致使更多的电子商家和消费

3、者之间建立畅通便捷的沟通和交易渠道，减少了企业的开支，减少了人们的不必要的时间浪费，为人们提供了周到和人性化的服务。为此我们选择了网上购物系统这个课题，以实现对网上交易等网上购物的一些探索和实践。开发后的网上系统包括六个模块即：普通客户模块、会员管理模块、管理员模块、系统管理模块、商品管理系统和在线购物模块。通过网上购物系统的建设以及实现对商业零售企业提供信息化管理。本文研究了一种基于数据关联规则网上购物系统，此方案与现今网上已采用的一些方案相比，具有用户使用更简单、界面更直观等优点。本系统基于HTML语言,嵌套了JSP编程技术。以JSH架构为环境,达到网上购物的目的。本篇着重论述了网上购物的

4、可行性、网上购物的优势、系统功能与实现、数据流程及存储，包括商品目录，会员注册、网上订购与购物、库存查询、后台数据管理等。关键词：网上购物; jsp; 购物车; 数据库第一章 绪论1.1网上购物系统概述随着因特网的不断普及和信息高速公路的逐步延伸,人类社会现今已昂首步入信息社会时代,而商品交易模式在不断地发生着变化，从古老的以物换物到货币等价交换，到现在的看似虚拟的交换却有真更好的服务，服务的好坏严重的影响着交易好坏的进行。在社会化大生产以及社会分工日趋专业化的今天，网上购物无形的 占据着主要的地位。网上购物系统一般由商品管理、购物车管理、系统管理和会员管理等要素组成，是一个网上交易过程。其主

5、要任务是交易各方以电子交易方式而不是通过当面交换或直接面谈方式进行的任何形式的商业交易。显然，这与“网上购物”的概念和内容既有联系，又有明显的区别。它们涉及的信息范围，服务功能以及社会意义等都不相同。网上购物系统搜集和管理的是特定的信息，其范围较窄，功能和目标比较明确、具体，主要是为特定的领域和机构的决策和管理服务；而信息管理则要对各类信息及其相关要素进行全方位管理，而对全社会开展信息服务，以便有效地满足社会的信息需求。今天，我们可以确信网上购物毋庸置疑是未来的发展方向。然而网上购物系统却还没有一个严格的定义。Intel公司认为：网上购物=电子市场电子交易电子服务；IBM认为：网上购物=web

6、；HP公司则说：“网上购物是通过电子化的手段来完成商业贸易活动的一种方式。”如此等等。那么究竟什么是网上购物系统呢？1.2 系统开发背景网上购物起源于七十年代。当时一些大公司通过建立自己的计算机网络实现各个机构之间、商业伙伴之间的信息共享，这个过程被称为EDI（电子数据交换）。EDI通过传递标准的数据流可以避免人为的失误、降低成本、提高效率，据估计在世界1000个最大的企业中，95%以上的在使用这一技术。它过去是、现在也是网上购物的基础。近年来，随着信息的全球化和国际互联网的普及化，越来越多的人想使用其无国界、无时间、无地域限制的便利环境来经营拓展商务。因此网上购物成为互联网应用的最大热点，越

7、来越多的企业通过使用网上购物技术来进行商业上的交易以减少成本。当然，还有更多的公司想使用网络技术来架构一个虚拟的店面进行营业交易，企业与消费者通过网络完成交易，非但能使企业降低成本也可以让消费者在一个舒适的地点享受逛街与购物的乐趣。随着网上购物风潮的扩大，将会有更多的公司连上网络进行各项业务，而不只是将公司产品介绍的网页放在网站上供人浏览而已。现在，大多数企业已经建立自己的网站介绍和销售他们的产品。您只要拥有一个计算机、浏览器、Internet连接和信用卡，今天就可以从网络上购买到书本、CD、鲜花、飞机票、电视甚至到汽车。如今网上购物已经成为企业增加市场竞争力的一种重要手段，同时人民购物更加方

8、便快捷。第二章 技术概述21什么事JSP，JSP的特点？ JSP技术使用Java编程语言编写类XML的tags和scriptlets，来封装产生动态网页的处理逻辑。网页还能通过tags和scriptlets访问存在于服务端的资源的应用逻辑。JSP将网页逻辑与网页设计和显示分离，支持可重用的基于组件的设计，使基于Web的应用程序的开发变得迅速和容易。Web服务器在遇到访问JSP网页的请求时，首先执行其中的程序段，然后将执行结果连同JSP文件中的HTML代码一起返回给客户。插入的Java程序段可以操作数据库、重新定向网页等，以实现建立动态网页所需要的功能。JSP与Java Servlet一样，是在

9、服务器端执行的，通常返回给客户端的就是一个HTML文本，因此客户端只要有浏览器就能浏览。JSP的1.0规范的最后版本是1999年9月推出的，12月又推出了1.1规范。目前较新的是JSP1.2规范，JSP2.0规范的征求意见稿也已出台。JSP页面由HTML代码和嵌入其中的Java代码所组成。服务器在页面被客户端请求以后对这些Java代码进行处理，然后将生成的HTML页面返回给客户端的浏览器。Java Servlet 是JSP的技术基础，而且大型的Web应用程序的开发需要Java Servlet和JSP配合才能完成。JSP具备了Java技术的简单易用，完全的面向对象，具有平台无关性且安全可靠，主要

10、面向因特网的所有特点。自JSP推出后，众多大公司都支持JSP技术的服务器，如IBM、Oracle、Bea公司等，所以JSP迅速成为商业应用的服务器端语言。JSP可用一种简单易懂的等式表示为：HTML+Java=JSP。2.2 JSP的特点2.2.1一次编写，到处运行。除了系统之外，代码不用做任何更改。2.2.2系统的多平台支持。基本上可以在所有平台上的任意环境中开发，在任环境中进行系统部署，在任意环境中扩展。相比ASP/.net的局限性是显而易2.2.3强大的可伸缩性。从只有一个小的Jar文件就可以运行Servlet/JSP，到由多台服务器进行集群和负载均衡，到多台Application进行事

11、务处理，消息处理，一台服务器到无数台服务器，Java显示了一个巨大的生命力。2.2.4多样化和功能强大的开发工具支持。这一点与ASP很像，Java已经有了许多非常优秀的开发工具，而且许多可以免费得到，并且其中许多已经可以顺利的运行于多种平台之下。2.2.5支持服务器端组件。web应用需要强大的服务器端组件来支持，开发人员需要利用其他工具设计实现复杂功能的组件供web页面调用，以增强系统性能。JSP可以使用成熟的JAVA BEANS 组件来实现复杂商务功能。2.3Hibernate 技术2.3.1 Hibernate优点对象/关系数据库映射(ORM)它使用时只需要操纵对象，使开发更

12、对象化，抛弃了数据库中心的思想，完全的面向对象思想透明持久化(persistent)带有持久化状态的、具有业务功能的单线程对象，此对象生存期很短。这些对象可能是普通的JavaBeans/POJO，这个对象没有实现第三方框架或者接口，唯一特殊的是他们正与（仅仅一个）Session相关联。一旦这个Session被关闭，这些对象就会脱离持久化状态，这样就可被应用程序的任何层自由使用。（例如，用作跟表示层打交道的数据传输对象。） 事务Transaction(org.hibernate.Transaction) 应用程序用来指定原子操作单元范围的对象，它是单线程的，生命周期很

13、短。它通过抽象将应用从底层具体的JDBC、JTA以及CORBA事务隔离开。某些情况下，一个Session之内可能包含多个Transaction对象。尽管是否使用该对象是可选的，但无论是使用底层的API还是使用Transaction对象，事务边界的开启与关闭是必不可少的。 它没有侵入性，即所谓的轻量级框架 移植性会很好 缓存机制，提供一级缓存和二级缓存 简洁的HQL编程 2.3.2 Hibernate缺点 Hibernate在批量数据处理时有弱势 针对单一对象简单的增删查改，适合于Hibernate,而对于批量的

14、修改，删除，不适合用Hibernate,这也是OR框架的弱点；要使用数据库的特定优化机制的时候，不适合用Hibernate 2.4Spring技术2.4.1Spring技术的特点 轻量级(Lightweight):轻量级有两层含义,其一,体积大小,其二,系统开销部署的时候仅需要一个比1M大一点儿的JAR包,而在系统中其所用开销几乎可以忽略 .控制反转(Inversion of control):Spring使用IoC来解耦对象不再依赖于其它对象来创建自身,而是依赖于容器 .面向切面(Aspect-oriented):Spring 运用 面向切面编程(A

15、OP)来把业务逻辑分离的模块粘合到一起 容器(Container):Spring从某种意义上来说,它是一个管理生命周期 和 配置应用对象的容器 框架(Framework):Spring让把普通的组件通过配置和组合的方式,形成复杂应用程序成为一种可能2.4.2Spring框架图：2.4.3 Spring Web MVC的实现 关于MVC，这是和WEB开发相关的部分，显然大家都是很熟悉了。从最初的JSP到struts，再到像wicket等等，真是百花齐放，百家争鸣.在WEB UI上，这部分是做web应用架构选择不可缺少的一部分。而作为MVC框架，也许SPRING MVC

16、不能算得上是表现力最出色的UI框架，但无疑，它的实现也是非常的优秀，同时，我们可以从它的实现上，看到一个非常清晰的MVC实现的过程，从这点上看，真是非常的过瘾啊！ 在了解IOC容器的基本实现的基础上，下面我们来看看，在典型的Web环境中，Spring IOC容器是如何在Web环境中被载入并起作用的。我们可以看到，对于MVC这部分，主要建立在IOC的基础上，AOP的特性应用得并不多。Spring并不是天生就能在Web容器中起作用的，同样也需要一个启动过程，把自己的IOC容器导入，并在Web容器中建立起来。 与对IoC容器的初始化的分析一样，我们同样看到了loadBeanDefinition对Be

17、anDefinition的载入。在Web环境中，对定位BeanDefinition的Resource有特别的要求，对这个要求的处理体现在getDefaultConfigLocations方法的处理中。可以看到，在这里，使用了默认的BeanDefinition的配置路径，这个路径在XmlWebApplicationContext中，已经作为一个常量定义好了，这个常量就是/WEB-INF/applicationContext.xml。这里的loadBeanDefinition实现如下所示：Java代码1 public class XmlWebApplicationContext extends A

18、bstractRefreshableWebApplicationContext 2 /* Default config location for the root context */3 /这里是设置缺省BeanDefinition的地方，在/WEB-INF/applicationContext.xml文件里，如果不特殊指定其他文件，IoC容器会从这里读取BeanDefinition来初始化IoC容器4 public static final String DEFAULT_CONFIG_LOCATION = /WEB-INF/applicationContext.xml; 5 /* Defau

19、lt prefix for building a config location for a namespace */6 public static final String DEFAULT_CONFIG_LOCATION_PREFIX = /WEB-INF/; 7 /* Default suffix for building a config location for a namespace */8 public static final String DEFAULT_CONFIG_LOCATION_SUFFIX = .xml; 9 /我们又看到了熟悉的loadBeanDefinition,

20、就像我们前面对IOC容器的分析一样，这个加载过程在容器refresh()时启动。10 protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException 11 / Create a new XmlBeanDefinitionReader for the given BeanFactory.12 / 对于XmlWebApplicationContext,当然是使用XmlBeanDefinitionReader来对BeanDefinition信息进行解析13 XmlBeanDef

21、initionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory); 14 / Configure the bean definition reader with this contexts15 / resource loading environment.16 / 这里设置ResourceLoader,因为XmlWebApplicationContext是DefaultResource的子类，所以这里同样会使用DefaultResourceLoader来定位BeanDefinition 17 beanDe

22、finitionReader.setResourceLoader(this); 18 beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this); 19 / Allow a subclass to provide custom initialization of the reader,20 / then proceed with actually loading the bean definitions.21 initBeanDefinitionReader(beanDefinitionReader); 22

23、/这里使用定义好的XmlBeanDefinitionReader来载入BeanDefinition23 loadBeanDefinitions(beanDefinitionReader); 24 25 protected void initBeanDefinitionReader(XmlBeanDefinitionReader beanDefinitionReader) 26 27 /如果有多个BeanDefinition的文件定义，需要逐个载入，都是通过reader来完成的，这个初始化过程是由refreshBeanFactory方法来完成的，这里只是负责载入BeanDefinition28

24、protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException 29 String configLocations = getConfigLocations(); 30 if (configLocations != null) 31 for (String configLocation : configLocations) 32 reader.loadBeanDefinitions(configLocation); 33 public class XmlW

25、ebApplicationContext extends AbstractRefreshableWebApplicationContext /* Default config location for the root context */ /这里是设置缺省BeanDefinition的地方，在/WEB-INF/applicationContext.xml文件里，如果不特殊指定其他文件，IoC容器会从这里读取BeanDefinition来初始化IoC容器 public static final String DEFAULT_CONFIG_LOCATION = /WEB-INF/applicat

26、ionContext.xml; /* Default prefix for building a config location for a namespace */ public static final String DEFAULT_CONFIG_LOCATION_PREFIX = /WEB-INF/; /* Default suffix for building a config location for a namespace */ public static final String DEFAULT_CONFIG_LOCATION_SUFFIX = .xml; /我们又看到了熟悉的l

27、oadBeanDefinition,就像我们前面对IOC容器的分析一样，这个加载过程在容器refresh()时启动。 protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException / Create a new XmlBeanDefinitionReader for the given BeanFactory. / 对于XmlWebApplicationContext,当然是使用XmlBeanDefinitionReader来对BeanDefinition信息进行解析 X

28、mlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory); / Configure the bean definition reader with this contexts / resource loading environment. / 这里设置ResourceLoader,因为XmlWebApplicationContext是DefaultResource的子类，所以这里同样会使用DefaultResourceLoader来定位BeanDefinition beanDef

29、initionReader.setResourceLoader(this); beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this); / Allow a subclass to provide custom initialization of the reader, / then proceed with actually loading the bean definitions. initBeanDefinitionReader(beanDefinitionReader); /这里使用定义好的XmlBe

30、anDefinitionReader来载入BeanDefinition loadBeanDefinitions(beanDefinitionReader); protected void initBeanDefinitionReader(XmlBeanDefinitionReader beanDefinitionReader) /如果有多个BeanDefinition的文件定义，需要逐个载入，都是通过reader来完成的，这个初始化过程是由refreshBeanFactory方法来完成的，这里只是负责载入BeanDefinition protected void loadBeanDefinit

31、ions(XmlBeanDefinitionReader reader) throws BeansException, IOException String configLocations = getConfigLocations(); if (configLocations != null) for (String configLocation : configLocations) reader.loadBeanDefinitions(configLocation); 进入DispatcherServlet和MVC实现 完成了在Web环境中，IoC容器的建立以后，也就是在完成对Context

32、LoaderListener的初始化以后，Web容器开始初始化DispatcherServlet，接着，会执行DispatcherServlet持有的IoC容器的初始化过程，在这个初始化过程中，一个新的上下文被建立起来，这个DispatcherServlet持有的上下文，被设置为根上下文的子上下文。可以大致认为，根上下文是和Web应用相对应的一个上下文，而DispatcherServlet持有的上下文是和Servlet对应的一个上下文，在一个Web应用中，往往可以容纳多个Servlet存在；与此相对应，对于应用在Web容器中的上下体系，也是很类似的，一个根上下文可以作为许多Servlet上下文

33、的双亲上下文。在DispatcherServlet，我们可以看到对MVC的初始化，是在DispatcherServlet的initStrategies完成的。 在这个初始化完成以后，会在上下文中建立器一个执行器于url的对应关系，这个对应关系可以让在url请求到来的时候，MVC可以检索到相应的控制器来进行处理，如以下代码所示：Java代码 34 protected Object getHandlerInternal(HttpServletRequest request) throws Exception 35 /这里从request中得到请求的url路径36 String lookupPath

34、 = this.urlPathHelper.getLookupPathForRequest(request); 37 /这里使用得到的url路径对Handler进行匹配，得到对应的Handler，如果没有对应的Hanlder，返回null，这样默认的Handler会被使用38 Object handler = lookupHandler(lookupPath, request); 39 if (handler = null) 40 / We need to care for the default handler directly, since we need to41 / expose th

35、e PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE for it as well.42 Object rawHandler = null; 43 if (/.equals(lookupPath) 44 rawHandler = getRootHandler(); 45 46 if (rawHandler = null) 47 rawHandler = getDefaultHandler(); 48 49 if (rawHandler != null) 50 validateHandler(rawHandler, request); 51 handler = buil

36、dPathExposingHandler(rawHandler, lookupPath, null); 52 53 54 if (handler != null & logger.isDebugEnabled() 55 logger.debug(Mapping + lookupPath + to handler + handler + ); 56 57 else if (handler = null & logger.isTraceEnabled() 58 logger.trace(No handler mapping found for + lookupPath + ); 59 60 ret

37、urn handler; 61 62 / lookupHandler是根据url路径，启动在handlerMap中对handler的检索，并最终返回handler对象63 protected Object lookupHandler(String urlPath, HttpServletRequest request) throws Exception 64 / Direct match?65 Object handler = this.handlerMap.get(urlPath); 66 if (handler != null) 67 validateHandler(handler, re

38、quest); 68 return buildPathExposingHandler(handler, urlPath, null); 69 70 / Pattern match?71 String bestPathMatch = null; 72 for (String registeredPath : this.handlerMap.keySet() 73 if (getPathMatcher().match(registeredPath, urlPath) & 74 (bestPathMatch = null | bestPathMatch.length() registeredPath

39、.length() 75 bestPathMatch = registeredPath; 76 77 78 if (bestPathMatch != null) 79 handler = this.handlerMap.get(bestPathMatch); 80 validateHandler(handler, request); 81 String pathWithinMapping = getPathMatcher().extractPathWithinPattern(bestPathMatch, urlPath); 82 Map uriTemplateVariables = 83 ge

40、tPathMatcher().extractUriTemplateVariables(bestPathMatch, urlPath); 84 return buildPathExposingHandler(handler, pathWithinMapping, uriTemplateVariables); 85 86 / No handler found.87 return null; 88 protected Object getHandlerInternal(HttpServletRequest request) throws Exception /这里从request中得到请求的url路

41、径 String lookupPath = this.urlPathHelper.getLookupPathForRequest(request); /这里使用得到的url路径对Handler进行匹配，得到对应的Handler，如果没有对应的Hanlder，返回null，这样默认的Handler会被使用 Object handler = lookupHandler(lookupPath, request); if (handler = null) / We need to care for the default handler directly, since we need to / exp

42、ose the PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE for it as well. Object rawHandler = null; if (/.equals(lookupPath) rawHandler = getRootHandler(); if (rawHandler = null) rawHandler = getDefaultHandler(); if (rawHandler != null) validateHandler(rawHandler, request); handler = buildPathExposingHandler(ra

43、wHandler, lookupPath, null); if (handler != null & logger.isDebugEnabled() logger.debug(Mapping + lookupPath + to handler + handler + ); else if (handler = null & logger.isTraceEnabled() logger.trace(No handler mapping found for + lookupPath + ); return handler; / lookupHandler是根据url路径，启动在handlerMap

44、中对handler的检索，并最终返回handler对象 protected Object lookupHandler(String urlPath, HttpServletRequest request) throws Exception / Direct match? Object handler = this.handlerMap.get(urlPath); if (handler != null) validateHandler(handler, request); return buildPathExposingHandler(handler, urlPath, null); / Pa

45、ttern match? String bestPathMatch = null; for (String registeredPath : this.handlerMap.keySet() if (getPathMatcher().match(registeredPath, urlPath) & (bestPathMatch = null | bestPathMatch.length() registeredPath.length() bestPathMatch = registeredPath; if (bestPathMatch != null) handler = this.handl

46、erMap.get(bestPathMatch); validateHandler(handler, request); String pathWithinMapping = getPathMatcher().extractPathWithinPattern(bestPathMatch, urlPath); Map uriTemplateVariables = getPathMatcher().extractUriTemplateVariables(bestPathMatch, urlPath); return buildPathExposingHandler(handler, pathWithinMapping, uriTemplateVariables); / No h