电子商务系统设计与实现第7章课件_第1页
电子商务系统设计与实现第7章课件_第2页
电子商务系统设计与实现第7章课件_第3页
电子商务系统设计与实现第7章课件_第4页
电子商务系统设计与实现第7章课件_第5页
已阅读5页,还剩79页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

电子商务系统设计与实现厉小军副教授lixj@浙江工商大学计算机与信息工程学院电子商务系统设计与实现厉小军副教授课程的主要内容第1章概论第2章电子商务系统分析与设计基础第3章电子商务系统开发基础第4章电子商务系统规划第5章电子商务系统分析第6章电子商务系统设计第7章电子商务应用系统设计第8章数据库实现第9章电子商务网站开发技术第10章电子商务系统的开发模式第11章电子商务系统的测试与维护课程的主要内容第1章概论第7章电子商务应用系统设计7.1电子商务应用系统的功能7.2电子商务应用系统的体系结构7.3电子商务网站的设计7.4数据库的设计7.5电子商务支付系统的设计7.6电子商务安全系统的设计第7章电子商务应用系统设计7.1电子商务应用系统的功能7.1电子商务应用系统的功能从系统构成角度上看,一个电子商务系统往往包含以下几部分的功能:(1)商品动态展示和管理功能(2)交易功能(3)用户/商家管理功能(4)在线反馈沟通功能(5)汇总统计功能7.1电子商务应用系统的功能从系统构成角度上看,一个电子商7.2电子商务应用系统的体系结构体系结构是具有一定形式的结构化元素(即构件)的集合,包括处理构件、数据构件和连接构件。电子商务应用系统的体系结构主要包括:客户/服务器体系结构三层体系结构多层体系结构MVC体系结构7.2电子商务应用系统的体系结构体系结构是具有一定形式的结7.2.1客户/服务器体系结构Client/Server,简称C/S结构在客户/服务器体系结构中,处理被分散在两台机器上:客户机和服务器。客户机一般负责信息系统图形显示、数据录入和业务处理等,而服务器则提供对数据的存储和管理。服务器通常专用于运行一个关系型数据库管理系统(简称RDMS),例如Oracle或SQLServer的服务器。这种结构实现了分布式计算,降低了服务器端的负载,并有助于在企业内实现对业务数据的集中式管理。可以减少网络上交换的数据量,并提高系统的运行效率和网络的稳定性。7.2.1客户/服务器体系结构Client/Server,图7.1客户/服务器体系结构

7.2.1客户/服务器体系结构图7.1客户/服务器体系结构7.2.1客户/服务器从80年代后期到90年代初,各个公司都积极地采用两层体系结构,可以快速地构建应用程序。然而不久,人们就发现了这种体系结构的缺点:对客户端软、硬件的配置要求较高,增加了整个系统的成本。对业务逻辑和表示逻辑的更新必须被部署到所有客户机,当客户机数量较大时,这项工作变的非常难以实施。随着系统的发展,客户机上将业务逻辑和表示逻辑混合在一起,设计越来越复杂,并且为升级维护带来难以想象的难度。客户/服务器体系结构是单一服务器且以局域网络为中心的,所以难以扩展到大型企业广域网或Internet。客户机不可能共享诸如数据库连接等稀有资源。因为它需要花费几秒的时间来建立数据库连接,于是两层体系结构的客户机一般会提前打开连接,并且在会话的持续时间内将一直保持该连接。所以一个允许20个并发连接的数据库只能为20个客户机应用程序服务,即使其中许多应用程序闲置,闲置的客户机还是会占用服务器的连接。客户机直接连接数据库同时也为数据安全带来了很大的隐患。7.2.1客户/服务器体系结构从80年代后期到90年代初,各个公司都积极地采7.2.2三层体系结构Browser/Server,简称B/S结构B/S结构是三层或多层C/S结构的一种实现方式。其主要特点是:客户端一般是一个浏览器,业务逻辑部署在Web服务器上。这样客户机不再负责处理复杂计算和数据访问等功能,主要负责与用户的交互。系统的绝大多数处理功能都放在Web层上,所有的应用系统、业务逻辑和控制都在这一层上,对数据库的访问也放在这一层上。数据库服务器负责存储大量的数据信息和数据逻辑,所有与数据有关的安全、完整性控制、数据的一致性、并发操作等都是在第三层完成。三层体系结构并不是指一定要把三层部署在分别不同的计算机上,而是指在软件的层次结构上要把三层分开。7.2.2三层体系结构Browser/Server,简称B图7.2三层体系结构7.2.2三层体系结构图7.2三层体系结构7.2.2三层体系结构7.2.3多层体系结构随着应用的规模越来越大,功能越来越复杂,很有必要对软件系统再进行分层处理。这样就构成了多层体系结构。例如某些大型集团有遍布全国的分公司,在开发大集中型的软件时,可能将应用通讯层分离出来,构成客户层-应用通讯层-应用服务器-数据库服务器的四层结构。而在基于Web的软件中,目前已有很多大型软件将中间层分为Web层和应用服务层,前者负责系统的表示逻辑,后者负责系统的业务逻辑。7.2.3多层体系结构随着应用的规模越来越大,功能越来越复多层体系结构的优点因为客户端不包含业务逻辑,所以它们变得更加简洁。这就使部署和维护工作更加容易,因为更新业务逻辑只需要对应用服务器进行操作。假如业务逻辑层是最易发生变化的层次,那么这个优点将更加显著。客户机与数据库相分离。应用服务器能够与几个不同的数据源协同工作,并且只对客户机提供单一的访问点。多层编程促进了应用层的严格划分,并使各层间通过定义好的接口进行通信。从长远的观点看,这样为维护提供了更多的方便,因为不用改变层的接口就可以对它的实现进行更新。多层应用程序能够水平伸缩。如果设计正确,业务逻辑就能够被复制和分布到几个负载均衡的应用服务器上。如果用户需求增加,则可以添加更多的服务器以满足要求。应用服务器能将稀有的企业资源(如数据库连接)放入缓冲池中,这样可以在多个客户机上共享它们。多层体系结构的优点因为客户端不包含业务逻辑,所以它们变得更加多层体系结构的缺点实现比较困难。在关键点上设计不好将会削弱多层应用程序的作用,而且它的性能和伸缩性都不比它所取代的两层应用程序更有优势。多层体系结构的缺点实现比较困难。7.2.4MVC体系结构MVC是把一个应用的输入、处理、输出流程按照模型、视图、控制的方式进行分离,这样应用被分为三个层:模型层、视图层、控制层。模型层(Model):负责表达和访问商业数据,执行业务逻辑和操作。视图层(View):把表示模型数据及逻辑关系和状态的信息及特定形式展示给用户。控制层(Control):定义了抽象的业务逻辑,用于控制业务流程。模型是应用对象,没有用户界面。视图表示它在屏幕上的显示,代表流向用户的数据。控制器定义用户界面对用户输入的响应方式,负责把用户的动作转成针对模型的操作。模型通过更新视图的数据来反映数据的变化。7.2.4MVC体系结构MVC是把一个应用的输入、处理、输图7.3GUI程序中的MVC7.2.4MVC体系结构图7.3GUI程序中的MVC7.2.4MVC体系结图7.4web应用中的MVC7.2.4MVC体系结构图7.4web应用中的MVC7.2.4MVC体系结MVC的实例MVC是目前很常见的J2EE应用所基于的体系结构,MVC主要适用于交互式的WEB应用,尤其是存在大量页面、多次客户访问及数据显示。其实MVC只是一种设计思想,而怎么实现MVC,则有很多途径,开发人员可以采用已有的框架(如Struts、WebWork等)来实现,也可以自己构建一个MVC框架。本书所附光盘中的例子JPetStore采用Struts这一流行的MVC框架,视图采用JSP技术,而存储层采用了iBATIS这一O/RMapping(Object-RelationMapping,对象关系映射)技术。MVC的实例MVC是目前很常见的J2EE应用所基于的体系结构7.3电子商务网站的设计电子商务系统中,网站往往都具有重要作用,本节内容主要介绍电子商务网站的基本要求、网站的结构构成和网站的设计方法。7.3电子商务网站的设计电子商务系统中,网站往往都具有重要7.3.1电子商务网站的基本要求(1)界面友好,使用方便(2)访问速度快(3)兼容性(4)可扩充性(5)较高的安全性(6)提供稳定的7×24服务(7)注重保护个人信息7.3.1电子商务网站的基本要求(1)界面友好,使用方便7.3.2电子商务网站的结构网站的物理结构文件应根据其功能、层次来存放,而不应将所有的文件都放在根目录下。根据栏目规划来设计目录结构,目录的层次不宜太多。目录名应使用简单易识别的英文字母,不要使用中文目录名。数据库文件应单独放置,同时注意设置好访问权限。不同目录的权限配置要合理,如:对于静态网页只要可读即可,如果是执行文件,还需执行的权限。将可执行文件与不可执行文件分开放置。网站的逻辑链接结构要符合浏览者的思维习惯和浏览习惯。要使网站中最重要的信息有最多的机会与浏览者见面。7.3.2电子商务网站的结构网站的物理结构7.3.3电子商务网站的设计方法(1)网站风格的选择和创意的使用(2)网站总体形象设计(3)网站栏目设置(4)网页布局(5)网页色彩的搭配技巧例:IBM公司的网站>>7.3.3电子商务网站的设计方法(1)网站风格的选择和创意电子商务系统设计与实现第7章课件7.4数据库的设计数据库设计是指对于一个给定的应用环境,从用户对数据的需求出发,研究并构造数据库结构,使之能够有效的存储数据,满足用户的各种应用需求的过程。7.4数据库的设计数据库设计是指对于一个给定的应用环境,从7.4.1关系型数据库的基本概念(1)关系型数据库(2)主键(3)关系(4)视图(5)存储过程(6)E-R图7.4.1关系型数据库的基本概念(1)关系型数据库7.4.2数据库设计的基本原则(1)数据库设计的基本规则――范氏构造数据库必须遵循一定的规则,在关系数据库中,这种规则就是范式。范式是符合某一种级别的关系模式的集合。7.4.2数据库设计的基本原则(1)数据库设计的基本规则―①第一范式(1NF)第一范式要求数据表不能存在重复的记录,即每个表应存在一个关键字。第一范式的第二个要求是每个字段都不可再分,即已经分到最小。主关键字达到下面几个条件:主关键字段在表中是唯一的;主关键字段中没有复本;主关键字段不能存在空值;每条记录都必须有一个主关键字;主关键字是关键字的最小子集。①第一范式(1NF)第一范式要求数据表不能存在重复的记录,即②第二范式(2NF)如果一个关系属于1NF,且所有的非主关键字段都完全地依赖于主关键字,则称之为第二范式,简记为2NF。②第二范式(2NF)如果一个关系属于1NF,且所有的非主关键③第三范式(3NF)定义:如果一个关系属于2NF,且每个非关键字不传递依赖于主关键字,这种关系是3NF。从2NF中消除传递依赖,就是3NF。③第三范式(3NF)定义:如果一个关系属于2NF,且每个非关(2)电子商务系统数据库设计的基本原则

真实性:正确反映数据与数据(信息与信息)之间的层次逻辑关系。准确性:对进入到数据库中的数据有一个有效性检查。完整性:对数据库中的数据进行非逻辑操作进行相应的错误处理。实用性:满足应用功能需求、满足系统对性能上的要求。(2)电子商务系统数据库设计的基本原则真实性:正确反映数据7.4.3基于UML的数据库设计对关系数据库来说,目前比较常用的设计方法是采用E-R图,但越来越多的人开始采用UML类图进行数据库设计。相比较而言,UML类图的描述能力更强,不但可以对数据表建模,还可以对触发器和存储过程等建模。在基于UML的面向对象系统分析完成后,我们已经得到了类图,进而可以方便地采用类图进行数据库设计。我们可以用类图来描述数据库,用类描述数据库表,用类的操作来描述触发器和存储过程。7.4.3基于UML的数据库设计对关系数据库来说,目前比7.4.4数据模型与对象模型的关系及转换一般来说,将对象模型中的类映射成表,将类的属性映射成表的一个字段,而对象之间的关系在数据库中是通过使用外键来实现的。例:本书附带光盘中的JPetStore7.4.4数据模型与对象模型的关系及转换一般来说,将对象模数据模型与对象模型的关系及转换(1)把类的属性映射成表的字段。(2)把类映射成表①把整个类层次映射为单个数据库表,在表中保存所有类(父类、子类)的属性。②每个具体子类映射成单个数据库表,数据库表包括自身的属性和继承的属性。③每个类均映射为数据库表,父类所对应的表只包含父类的属性,各子类对应的表只包含子类的属性,父类表中的主键同时作为子类对应表的主键和外键。(3)关系的实现①一对一,一对多关系的映射②多对多关系的映射数据模型与对象模型的关系及转换(1)把类的属性映射成表的字段7.5电子商务支付系统的设计支付是电子商务活动中的重要一环。本节内容首先介绍支付系统的功能设计,然后介绍支付系统的数据流程、交易流程设计。7.5电子商务支付系统的设计支付是电子商务活动中的重要一环7.5.1支付系统的功能设计支付系统的功能设计主要涉及电子支付系统的三大部分,即客户端支付软件、支付服务器、支付网关。客户端支付软件:用户进行支付时使用的界面。支付服务器:与业务服务相关联的应用程序,通过一组标准的与具体业务不相关的支付控制API接口,支付服务器实现对多种业务模块的支持。支付网关:连接商家和银行专网的通信及交易桥梁。支付网关主要功能是负责保障通信、协议转换和数据加解密功能,及保护银行内部网络。7.5.1支付系统的功能设计支付系统的功能设计主要涉及电子7.5.2支付系统的交易流程设计(1)电子商务支付系统的数据流程用户终端选择相应的服务,将支付的请求发往应用服务器;应用服务器根据服务请求中的银行标识信息,将授权请求发往相应的支付服务器;支付服务器首先进行相应的支付信息、银行标识信息的校验,然后将请求发往相应的银行支付网关。银行完成处理后,银行支付网关将处理结果反馈给支付服务器;支付服务器将处理结果返回给应用服务器;应用服务器将处理结果发往业务系统;业务系统将根据用户服务请求信息提供相应的服务,并返回给应用服务器。应用服务器将信息反馈给用户终端。7.5.2支付系统的交易流程设计(1)电子商务支付系统的数(2)基于SSL协议的交易流程设计用户浏览商家网页,选购商品并洽谈合同;订单确定后,用户点击商家网页上的支付链接,链接到网上银行的支付页面;客户端激活SSL安全代理,弹出登录窗口,提示用户输入用户名、密码;系统自动完成和支付网关间证书的相互认证并建立SSL安全加密通道。交易序列号、用户账号、密码等机密信息则通过安全通道传递;如果登录成功,则进入网上支付服务网页;用户填入信息后点击确认,系统将提示用户确认信息并签名。如果确认,则该支付信息将被提交给支付网关处理。支付网关将用户支付授权信息按预先约定组成合法的消息包发给银行。如果交易金额在授权金额范围内,并且交易可以接受,银行系统将在处理后,把合同号、银行交易号、交易金额、交易时间、银行处理结果等信息通知商家;商家的支付服务器随后将支付处理结果发送给用户;如果交易金额超过授权金额,系统则通知用户支付失败。(2)基于SSL协议的交易流程设计用户浏览商家网页,选购商品(3)基于SET协议的交易流程设计一个完整的SET交易包括持卡人注册申请证书、商家注册申请证书、购买请求、支付授权、支付请款五个步骤。(3)基于SET协议的交易流程设计一个完整的SET交易包括持7.6电子商务安全系统的设计电子商务发展的基础是网络,即Internet/Intranet,而且其交易的双方不再是面对面的,而是被时空、距离所阻隔,网络的开放性和商务数据的敏感性保密性要求,使得电子商务的安全问题显得尤其重要。本节内容首先介绍电子商务安全系统框架,然后介绍电子商务安全的需求分析,最后介绍电子商务安全方案的制定。7.6电子商务安全系统的设计电子商务发展的基础是网络,即I7.6.1电子商务安全系统框架(1)硬件设备的物理安全(2)网络结构安全(3)网络通信安全(4)操作系统安全(5)数据库安全(6)应用安全(7)用户认证管理(8)安全管理(9)安全策略7.6.1电子商务安全系统框架(1)硬件设备的物理安全7.6.2电子商务安全的需求分析界定内部网络边界的安全性,如果内部局域网与公用网络相连,则为确保内部局域网边界的安全,需建立防火墙等安全设施。2007年春节前夕爆发的熊猫烧香病毒就是通过互联网感染局域网的一种恶性病毒,局域网中一台电脑感染,往往会祸及局域网中所有其他电脑,会导致局域网的崩溃。保证网络内部的安全,不仅要保证系统的安全,更要保证数据的安全。建立全网统一、有效的身份识别系统,实现用户的统一管理,并在此基础上实行统一有效的授权管理,实现用户和资源之间的严格访问控制。信息输入时要采用措施保证数据完整性和保密性。需要有较全面的审计、记录的机制,能对网络中发生的与安全有关的事件进行记录,以便事后进行责任认定和进行纠错处理。7.6.2电子商务安全的需求分析界定内部网络边界的安全性,7.6.3电子商务安全方案的制定(1)安全方案的内容 安全方案的内容主要分技术、组织机构、管理体系三个方面。技术体系方面:技术体系是对电子商务系统全面提供安全保护的技术保障体系。组织机构方面:企业应有和电子商务安全策略相配套的人员安排,包括人员配备、岗位设计、职责责任设计、业绩考核设计、技能及培训教育设计等。管理体系方面:安全方案中还需制定配套的管理体系,从法律和规章制度方面来确定安全技术体系的执行,主要包括安全管理制度的制定、实施和监督。7.6.3电子商务安全方案的制定(1)安全方案的内容(2)安全方案的制定安全方案主要包括以下四个基本点:基本防护实时监控和审计攻击响应恢复(2)安全方案的制定安全方案主要包括以下四个基本点:电子商务系统设计与实现厉小军副教授lixj@浙江工商大学计算机与信息工程学院电子商务系统设计与实现厉小军副教授课程的主要内容第1章概论第2章电子商务系统分析与设计基础第3章电子商务系统开发基础第4章电子商务系统规划第5章电子商务系统分析第6章电子商务系统设计第7章电子商务应用系统设计第8章数据库实现第9章电子商务网站开发技术第10章电子商务系统的开发模式第11章电子商务系统的测试与维护课程的主要内容第1章概论第7章电子商务应用系统设计7.1电子商务应用系统的功能7.2电子商务应用系统的体系结构7.3电子商务网站的设计7.4数据库的设计7.5电子商务支付系统的设计7.6电子商务安全系统的设计第7章电子商务应用系统设计7.1电子商务应用系统的功能7.1电子商务应用系统的功能从系统构成角度上看,一个电子商务系统往往包含以下几部分的功能:(1)商品动态展示和管理功能(2)交易功能(3)用户/商家管理功能(4)在线反馈沟通功能(5)汇总统计功能7.1电子商务应用系统的功能从系统构成角度上看,一个电子商7.2电子商务应用系统的体系结构体系结构是具有一定形式的结构化元素(即构件)的集合,包括处理构件、数据构件和连接构件。电子商务应用系统的体系结构主要包括:客户/服务器体系结构三层体系结构多层体系结构MVC体系结构7.2电子商务应用系统的体系结构体系结构是具有一定形式的结7.2.1客户/服务器体系结构Client/Server,简称C/S结构在客户/服务器体系结构中,处理被分散在两台机器上:客户机和服务器。客户机一般负责信息系统图形显示、数据录入和业务处理等,而服务器则提供对数据的存储和管理。服务器通常专用于运行一个关系型数据库管理系统(简称RDMS),例如Oracle或SQLServer的服务器。这种结构实现了分布式计算,降低了服务器端的负载,并有助于在企业内实现对业务数据的集中式管理。可以减少网络上交换的数据量,并提高系统的运行效率和网络的稳定性。7.2.1客户/服务器体系结构Client/Server,图7.1客户/服务器体系结构

7.2.1客户/服务器体系结构图7.1客户/服务器体系结构7.2.1客户/服务器从80年代后期到90年代初,各个公司都积极地采用两层体系结构,可以快速地构建应用程序。然而不久,人们就发现了这种体系结构的缺点:对客户端软、硬件的配置要求较高,增加了整个系统的成本。对业务逻辑和表示逻辑的更新必须被部署到所有客户机,当客户机数量较大时,这项工作变的非常难以实施。随着系统的发展,客户机上将业务逻辑和表示逻辑混合在一起,设计越来越复杂,并且为升级维护带来难以想象的难度。客户/服务器体系结构是单一服务器且以局域网络为中心的,所以难以扩展到大型企业广域网或Internet。客户机不可能共享诸如数据库连接等稀有资源。因为它需要花费几秒的时间来建立数据库连接,于是两层体系结构的客户机一般会提前打开连接,并且在会话的持续时间内将一直保持该连接。所以一个允许20个并发连接的数据库只能为20个客户机应用程序服务,即使其中许多应用程序闲置,闲置的客户机还是会占用服务器的连接。客户机直接连接数据库同时也为数据安全带来了很大的隐患。7.2.1客户/服务器体系结构从80年代后期到90年代初,各个公司都积极地采7.2.2三层体系结构Browser/Server,简称B/S结构B/S结构是三层或多层C/S结构的一种实现方式。其主要特点是:客户端一般是一个浏览器,业务逻辑部署在Web服务器上。这样客户机不再负责处理复杂计算和数据访问等功能,主要负责与用户的交互。系统的绝大多数处理功能都放在Web层上,所有的应用系统、业务逻辑和控制都在这一层上,对数据库的访问也放在这一层上。数据库服务器负责存储大量的数据信息和数据逻辑,所有与数据有关的安全、完整性控制、数据的一致性、并发操作等都是在第三层完成。三层体系结构并不是指一定要把三层部署在分别不同的计算机上,而是指在软件的层次结构上要把三层分开。7.2.2三层体系结构Browser/Server,简称B图7.2三层体系结构7.2.2三层体系结构图7.2三层体系结构7.2.2三层体系结构7.2.3多层体系结构随着应用的规模越来越大,功能越来越复杂,很有必要对软件系统再进行分层处理。这样就构成了多层体系结构。例如某些大型集团有遍布全国的分公司,在开发大集中型的软件时,可能将应用通讯层分离出来,构成客户层-应用通讯层-应用服务器-数据库服务器的四层结构。而在基于Web的软件中,目前已有很多大型软件将中间层分为Web层和应用服务层,前者负责系统的表示逻辑,后者负责系统的业务逻辑。7.2.3多层体系结构随着应用的规模越来越大,功能越来越复多层体系结构的优点因为客户端不包含业务逻辑,所以它们变得更加简洁。这就使部署和维护工作更加容易,因为更新业务逻辑只需要对应用服务器进行操作。假如业务逻辑层是最易发生变化的层次,那么这个优点将更加显著。客户机与数据库相分离。应用服务器能够与几个不同的数据源协同工作,并且只对客户机提供单一的访问点。多层编程促进了应用层的严格划分,并使各层间通过定义好的接口进行通信。从长远的观点看,这样为维护提供了更多的方便,因为不用改变层的接口就可以对它的实现进行更新。多层应用程序能够水平伸缩。如果设计正确,业务逻辑就能够被复制和分布到几个负载均衡的应用服务器上。如果用户需求增加,则可以添加更多的服务器以满足要求。应用服务器能将稀有的企业资源(如数据库连接)放入缓冲池中,这样可以在多个客户机上共享它们。多层体系结构的优点因为客户端不包含业务逻辑,所以它们变得更加多层体系结构的缺点实现比较困难。在关键点上设计不好将会削弱多层应用程序的作用,而且它的性能和伸缩性都不比它所取代的两层应用程序更有优势。多层体系结构的缺点实现比较困难。7.2.4MVC体系结构MVC是把一个应用的输入、处理、输出流程按照模型、视图、控制的方式进行分离,这样应用被分为三个层:模型层、视图层、控制层。模型层(Model):负责表达和访问商业数据,执行业务逻辑和操作。视图层(View):把表示模型数据及逻辑关系和状态的信息及特定形式展示给用户。控制层(Control):定义了抽象的业务逻辑,用于控制业务流程。模型是应用对象,没有用户界面。视图表示它在屏幕上的显示,代表流向用户的数据。控制器定义用户界面对用户输入的响应方式,负责把用户的动作转成针对模型的操作。模型通过更新视图的数据来反映数据的变化。7.2.4MVC体系结构MVC是把一个应用的输入、处理、输图7.3GUI程序中的MVC7.2.4MVC体系结构图7.3GUI程序中的MVC7.2.4MVC体系结图7.4web应用中的MVC7.2.4MVC体系结构图7.4web应用中的MVC7.2.4MVC体系结MVC的实例MVC是目前很常见的J2EE应用所基于的体系结构,MVC主要适用于交互式的WEB应用,尤其是存在大量页面、多次客户访问及数据显示。其实MVC只是一种设计思想,而怎么实现MVC,则有很多途径,开发人员可以采用已有的框架(如Struts、WebWork等)来实现,也可以自己构建一个MVC框架。本书所附光盘中的例子JPetStore采用Struts这一流行的MVC框架,视图采用JSP技术,而存储层采用了iBATIS这一O/RMapping(Object-RelationMapping,对象关系映射)技术。MVC的实例MVC是目前很常见的J2EE应用所基于的体系结构7.3电子商务网站的设计电子商务系统中,网站往往都具有重要作用,本节内容主要介绍电子商务网站的基本要求、网站的结构构成和网站的设计方法。7.3电子商务网站的设计电子商务系统中,网站往往都具有重要7.3.1电子商务网站的基本要求(1)界面友好,使用方便(2)访问速度快(3)兼容性(4)可扩充性(5)较高的安全性(6)提供稳定的7×24服务(7)注重保护个人信息7.3.1电子商务网站的基本要求(1)界面友好,使用方便7.3.2电子商务网站的结构网站的物理结构文件应根据其功能、层次来存放,而不应将所有的文件都放在根目录下。根据栏目规划来设计目录结构,目录的层次不宜太多。目录名应使用简单易识别的英文字母,不要使用中文目录名。数据库文件应单独放置,同时注意设置好访问权限。不同目录的权限配置要合理,如:对于静态网页只要可读即可,如果是执行文件,还需执行的权限。将可执行文件与不可执行文件分开放置。网站的逻辑链接结构要符合浏览者的思维习惯和浏览习惯。要使网站中最重要的信息有最多的机会与浏览者见面。7.3.2电子商务网站的结构网站的物理结构7.3.3电子商务网站的设计方法(1)网站风格的选择和创意的使用(2)网站总体形象设计(3)网站栏目设置(4)网页布局(5)网页色彩的搭配技巧例:IBM公司的网站>>7.3.3电子商务网站的设计方法(1)网站风格的选择和创意电子商务系统设计与实现第7章课件7.4数据库的设计数据库设计是指对于一个给定的应用环境,从用户对数据的需求出发,研究并构造数据库结构,使之能够有效的存储数据,满足用户的各种应用需求的过程。7.4数据库的设计数据库设计是指对于一个给定的应用环境,从7.4.1关系型数据库的基本概念(1)关系型数据库(2)主键(3)关系(4)视图(5)存储过程(6)E-R图7.4.1关系型数据库的基本概念(1)关系型数据库7.4.2数据库设计的基本原则(1)数据库设计的基本规则――范氏构造数据库必须遵循一定的规则,在关系数据库中,这种规则就是范式。范式是符合某一种级别的关系模式的集合。7.4.2数据库设计的基本原则(1)数据库设计的基本规则―①第一范式(1NF)第一范式要求数据表不能存在重复的记录,即每个表应存在一个关键字。第一范式的第二个要求是每个字段都不可再分,即已经分到最小。主关键字达到下面几个条件:主关键字段在表中是唯一的;主关键字段中没有复本;主关键字段不能存在空值;每条记录都必须有一个主关键字;主关键字是关键字的最小子集。①第一范式(1NF)第一范式要求数据表不能存在重复的记录,即②第二范式(2NF)如果一个关系属于1NF,且所有的非主关键字段都完全地依赖于主关键字,则称之为第二范式,简记为2NF。②第二范式(2NF)如果一个关系属于1NF,且所有的非主关键③第三范式(3NF)定义:如果一个关系属于2NF,且每个非关键字不传递依赖于主关键字,这种关系是3NF。从2NF中消除传递依赖,就是3NF。③第三范式(3NF)定义:如果一个关系属于2NF,且每个非关(2)电子商务系统数据库设计的基本原则

真实性:正确反映数据与数据(信息与信息)之间的层次逻辑关系。准确性:对进入到数据库中的数据有一个有效性检查。完整性:对数据库中的数据进行非逻辑操作进行相应的错误处理。实用性:满足应用功能需求、满足系统对性能上的要求。(2)电子商务系统数据库设计的基本原则真实性:正确反映数据7.4.3基于UML的数据库设计对关系数据库来说,目前比较常用的设计方法是采用E-R图,但越来越多的人开始采用UML类图进行数据库设计。相比较而言,UML类图的描述能力更强,不但可以对数据表建模,还可以对触发器和存储过程等建模。在基于UML的面向对象系统分析完成后,我们已经得到了类图,进而可以方便地采用类图进行数据库设计。我们可以用类图来描述数据库,用类描述数据库表,用类的操作来描述触发器和存储过程。7.4.3基于UML的数据库设计对关系数据库来说,目前比7.4.4数据模型与对象模型的关系及转换一般来说,将对象模型中的类映射成表,将类的属性映射成表的一个字段,而对象之间的关系在数据库中是通过使用外键来实现的。例:本书附带光盘中的JPetStore7.4.4数据模型与对象模型的关系及转换一般来说,将对象模数据模型与对象模型的关系及转换(1)把类的属性映射成表的字段。(2)把类映射成表①把整个类层次映射为单个数据库表,在表中保存所有类(父类、子类)的属性。②每个具体子类映射成单个数据库表,数据库表包括自身的属性和继承的属性。③每个类均映射为数据库表,父类所对应的表只包含父类的属性,各子类对应的表只包含子类的属性,父类表中的主键同时作为子类对应表的主键和外键。(3)关系的实现①一对一,一对多关系的映射②多对多关系的映射数据模型与对象模型的关系及转换(1)把类的属性映射成表的字段7.5电子商务支付系统的设计支付是电子商务活动中的重要一环。本节内容首先介绍支付系统的功能设计,然后介绍支付系统的数据流程、交易流程设计。7.5电子商务支付系统的设计支付是电子商务活动中的重要一环7.5.1支付系统的功能设计支付系统的功能设计主要涉及电子支付系统的三大部分,即客户端支付软件、支付服务器、支付网关。客户端支付软件:用户进行支付时使用的界面。支付服务器:与业务服务相关联的应用程序,通过一组标准的与具体业务不相关的支付控制API接口,支付服务器实现对多种业务模块的支持。支付网关:连接商家和银行专网的通信及交易桥梁。支付网关主要功能是负责保障通信、协议转换和数据加解密功能,及保护银行内部网络。7.5.1支付系统的功能设计支付系统的功能设计主要涉及电子7.5.2支付系统的交易流程设计(1)电子商务支付系统的数据流程用户终端选择相应的服务,将支付的请求发往应用服务器;应用服务器根据服务请求中的银行标识信息,将授权请求发往相应的支付服务器;支付服务器首先进行相应的支付信息、银行标识信息的校验,然后将请求发往相应的银行支付网关。银行完成处理后,银行支付网关将处理结果反馈给支付服务器;支付服务器将处理结果返回给应用服务器;应用服务器将处理结果发往业务系统;业务系统将根据用户服务请求信息提供相应的服务,并返回给应用服务器。应用服务器将信息反馈给用户终端。7.5.2支付系统的交易流程设计(1)电子商务支付系统的数(2)基于SSL

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论