毕业设计（论文）-NET+SQL_客户积分管理系统.doc

客户积分管理系统摘要：客户积分业务是利用覆盖各行业的pos网络终端和商户资源，把各种积分卡统一起来，促进消费、加强客户忠诚度的一种业务。因此，客户积分系统的实现必将促进企业资源的跨行业运用，为企业提供个性化服务模式和新的效益增长点，而近年来计算机软硬件技术的飞速发展为这一需求提供了良好的外部支持。本文利用.net等开发工具实现了客户积分业务处理系统和积分业务管理系统。关键词: 设计模式; 积分系统abstract: customer integral business is covering all sectors of the pos terminals and network operators resources, to unify the various points cards, promote consumption, and enhance customer loyalty as a business. therefore, system integration, will promote the realization of cross-industry enterprise resource use, providing personalized service model and the benefits of new growth points, and computer hardware and software technology in recent years the rapid development of demand for this provided a good external. this paper. net and other development tools to achieve the integration, and business processing systems integration business management system. key words: design patterns; points system 目录第一章 前言2第二章 数据库简介42.1 数据库的基本概念42.1.1 数据库系统的类型42.1.2 数据库系统的结构52.2 sql server 2000 简介6第三章 客户积分系统的系统分析83.2客户积分系统的需求分析10第四章 积分系统的具体实现154.1积分系统业务层的设计以及相关模式154.4积分系统业务逻辑的详细设计314.5积分系统数据库的设计404.7客户积分系统总体设计424.8积分业务管理系统的实现46参考文献49第一章 前言1.1课题的来源、研究背景及意义消费积分是目前各行业促进消费、加强客户忠诚度常用的手段之一。以积分为基础，商户还可以开展各种丰富多彩的积分换领、消费奖励等活动。目前积分系统主要是商户自己开发和维护，因此积分活动也通常局限于商户本身或其下属的分店，无法使积分活动发挥更大的作用。本课题关注的客户积分业务是希望利用现在己经普遍覆盖各行业的公用pos网络终端和商户资源，结合日渐发展的企业级分布式技术，将商户资源进行整合，把目前社会上层出不穷的积分卡统一起来，实现消费者积分在实体世界里的操作与运用。同时为企业提供跨行业、多渠道、多参数的积分奖励软件平台及相关服务，实现客户资源的跨行业运用，为企业寻求个性化服务模式和新的效益增长点。以客户积分系统为技术基础，零售业、交通运输业、酒店餐饮业、娱乐旅游业等可能拥有共同客户的商户组成积分奖励联盟。商户可通过客户积分平台与其协议商户连接，使消费者不仅能在本商户累积或换领积分，同时也能在所有协议商户处累积或换领积分，并且只需要利用在协议商户处安装的pos终端，即可在线查询积分累积情况，还可以进行跨商户的积分交叉兑换，换领奖品或服务等。 客户积分系统的实现将使商户节省活动奖品换领的人力、物力，共享消费者资源，增强积分对消费者吸引力，最终实现跨行业的积分奖励。客户积分的实现具有很多好处，例如:灵活多变的跨行业、跨产品积分奖励;跨商户积分奖励和换领;积分奖励物流自动化;增强各商户的一条龙服务、增加营业收入;发展商户服务优势、提高消费者忠诚度、刺激消费者在联盟商户的消费等等。本课题将设计实现的客户积分系统会为商户提供一个基于web的设置界面，而户可按多种参数设置积分奖励规则，如:消费金额、消费者等级、生日、时间、节日、推广产品等，无须在每次推广新活动前重复开发或改造系统。同时，商户可利用该查询获得消费者偏好、奖励活动效果等信息，从而相应设计、调整积分参数和比例，迎合不同消费者的喜好，迅速推出各种不同主题的优惠推广活动，使活动效果迅速提高。同时，积分业务处理系统将承担实时处理pos机用户积分请求的工作，可对商户联盟在全国乃至国外的客户提供统一积分服务，通过该系统实现了客户积分资源的跨行业共享。根据这三种主要分布式技术各自的特点和发展，同时鉴于客户积分系统需要支持多个商户通过互联网访问，数百pos机也要通过psin网络连入系统。系统的核心软件需要跨平台、跨地区运行。同时系统既有在线交易，又有脱机交易，是基于网络、大型关系数据库的实时分布式系统。而.net在开发、配置和管理分布式应用中具有优势，能够支持建立以服务器为中心的多级应用结构，并且技术本身发展多年，得到众多厂商产品的支持。因此我们选择.net作为客户积分系统的开发平台。第二章 数据库简介2.1 数据库的基本概念什么是数据库系统?简单地说，数据库系统是一种计算机化的数据保存系统，它以特有的数据存储方式将相关的数据内容整合在一起。我们可以将数据库本身想成是一个电子档案柜，在这个电子档案柜内，存放着一些电子数据文件。数据库系统主要的目的在于维护信息，并在必要时提供协助取得这些信息。2.1.1 数据库系统的类型数据库系统被使用的范围非常广泛，从一般的微电脑到大型主机都可以使用。一般来说，大型主机多倾向于使用多用户的数据库系统，而一般的微电脑、个人计算机则倾向于使用单用户数据库系统。这里所谓的单用户数据库系统，是指同时最多只能有一个用户存取数据库的内容，而多用户数据库系统，则允许多个用户同时存取数据库的内容。数据库系统的种类非常多，目前以关系型（relational）数据库系统最为常见，所谓的关系型数据库系统是以表（table）的类型将数据提供给用户，而所有的数据库操作都是利用旧的表来产生新的表。除了关系型数据库系统外，其他常见的数据库系统类型还有inverted list，hierarchic，network等数据库系统。2.1.2 数据库系统的结构不同的数据库系统有着不同的系统结构，毫无疑问，一个数据库结构并不能完全用于所有的数据库系统，在这里我们以被广泛认同的数据库结构ansi/sparc结构来进行说明。1. ansi/sparc结构在ansi/sparc结构中将数据库分为内部层（internal level）、概念层（conceptual level）以及外部层（external level）等三层，如图2-1所示。图2-1 数据库结构图内部层是最接近数据库实体存储位置的一层，与数据库数据实际存储方式有关，在内部层中以具体的方式来表示整个数据库。外部层是最接近用户的部分，与用户对数据的查看方式有关，在外部层中以用户看得懂的方式来表示部分数据库的内容，每个用户所查看的数据内容不同。概念层位于内部层与外部层之间，以用户看得懂的方式来表示整个数据库，提供每个用户一致的数据查看内容。不管是使用哪一种数据库系统，都只会影响到ansi/sparc结构的外部层以及概念层内容，而与内部层无关。例如，对于关系型数据库系统而言，在概念层中所看到的数据一定是以关系型的形式存在，在外部视域中所看的数据有可能会以关系型的形式存在，至于在内部层中的数据则一定不会是以关系型的形式存在。2. mapping对应在图2-2的详细结构图中，可以发现在内部层与概念层之间以及概念层与外部层之间各有一个对应（mapping）存在，分别对应着上下两层的内容。图2-2 数据库详细结构图概念/内部对应（conceptual/ internal mapping）位于概念层与内部层之间，定义数据库的概念视域内容与实际存储内容之间的对应关系。如果改变了数据库的存储结构，只要在这个对应中修改对应的内容就可以了，而不需要改变概念视域与外部视域的内容。外部/概念对应（external/conceptual mapping）位于外部层与概念层之间，定义特定外部视域与概念视域的对应关系，也就是定义外部视域所查看的部分数据库内容与整个数据库之间的关系。2.2 sql server 2000 简介sql server 2000 以其卓越的性能逐渐成为windows操作系统平台下进行数据库应用开发中较为理想的选择之一。sql server 2000 由一系列相互协作的组件构成，能最大程度地满足web站点和企业数据处理系统存储和分析数据的需要，这些组件主要包括10：1) 关系数据库组件，包括数据库引擎本身和应用程序与数据库引擎间通信所涉及的组件。2) 数据库构架，描述sql server数据库中定义的逻辑组件，以及如何在数据库文件中真正实现这些组件。3) 关系数据库引擎构架，描述服务器引擎的各项功能。这些功能使服务器引擎得以高效地处理大量并发用户的数据要求。4) 管理架构和复制构架，管理构架描述sql server 2000附带的易用工具和减少日常管理任务的sql server 动态配置功能；复制构架描述sql server 2000的复制组件以及如何使用这些组件在数据库间分发数据。5) 应用程序开发构架，描述sql server 2000 如何支持各类数据库编程api，使用户能够创建可靠的数据库应用程序。第三章 客户积分系统的系统分析3.1客户积分系统的系统结构在行业竞争日趋激烈的今天，仅靠降价、打折、加大广告宣传进行促销、招徕顾客的方式己经趋于传统而减少了其带来的商业效果，随着与国际市场的近一步接轨，诸多商家从西方的企业管理运作方面学到了很多的经验，经营手段也得到了一定的发展。积分活动的开展就是一个例子。目前这一活动在市场经济的很多领域遍地开花，如:银行卡、超市、酒店、酒楼、娱乐场所的消费积分，航空公司的里程积分，中国移动的消费积分、信用积分与在网积分，乃至网站的各类积分等。尽管名目繁多，但究其根底可以看出积分活动是消费者在一个商家消费量的一种变相统计。在一定的周期商家按这一统计对客户展开多种方式的回报，积分兑换(礼品、现金或二次消费优惠等)。如此商家留住了客户，客户得到了实惠，使得这种方式的促销活动产生了双赢的效果。客户积分累积的过程是商家吸引住既有客户群的第一目的和直接受益点。但商家对客户群资源的充分利用还有着深挖潜力的强烈需求。客户积分业务的目的是利用覆盖各行业的公用pos网络终端和商户资源，通过成熟的技术手段建设一个可以将商户资源整合的软件平台，为企业提供跨行业、多渠道、多参数的积分奖励兑换及相关服务，实现客户资源的跨行业运用，为企业寻求个性化服务模式和新的效益增长点。客户积分系统就是为了管理和处理客户积分业务而开发的。它主要包括积分业务管理系统和积分业务处理系统两个子系统。综合服务平台管理者可以通过积分业务管理系统所提供的设置界面，按多种参数设置积分奖励规则，为接入的商户灵活配置，如:消费金额，客户等级、生日，时间、节日、推广产品等，无须在每次新推广活动前重复开发或改造系统。同时，利用简易的“奖励参数调整界面”，还可获得由系统自动跟踪得到的消费者偏好，从而为接入企业商户提供决策建议，便于其相应设计、调整积分参数和比例，迎合不同消费者的喜好，迅速推出各种不同主题的优惠推广活动。客户积分系统的结构图如下所示:图3.1终合积分系统的结构图 图中灰色部分是客户积分系统的主要部分，包括业务处理系统的服务器、积分系统管理的场吧b服务器、数据库服务器等。3.2客户积分系统的需求分析客户积分系统主要包括两个部分:积分业务处理系统和积分业务场吧b管理系统。3.2.1积分业务处理系统业务处理系统主要处理从pos发送来的请求。可具体划分为如下请求:1.积分消费积分消费是指客户通过积分pos按商户制定的兑换规则将自己的积分换成现金抵扣消费款额的业务。流程如下:(1)客户在积分pos机上按提示刷积分卡并输入换现积分额，积分pos将信息传送至积分系统;(2)积分系统对信息包进行协议格式处理，与数据库中数据核对确认该客户的积分额换现额然后将数据回送积分pos，同时修改数据库中的相应数据。2.积分兑换服务积分兑换服务是指客户将自己的积分换成商户提供的服务(如游戏网站的在线时间、道具，sip的vip邮箱、数据业务流量等)的业务。流程示意图3.2如下:图.3-2积分兑换服务流程 (1)在积分pos机上刷客户的积分卡，输入本次兑换服务要用去的积分额，积分pos将信息传送给积分系统;积分系统核减数据库中该客户的积分余额，记录交易流水并(2a)将服务开通通知信息发送给服务提供商户业务主机，(2b)将可以进行兑换的确认信息回送至积分pos，交易完成;3.积分兑换奖品积分兑换奖品是指客户将自己的积分换成相应的实物奖品的业务。流程如下:(1)在积分pos机上刷客户的积分卡，输入本次奖品兑换要用去的积分额，积分pos将信息传送给积分系统;(2)积分系统核减数据库中该客户的积分余额，记录交易流水并将可以进行兑换的确认信息回送至积分pos，交易完成;4.积分交叉兑换积分交叉兑换是指客户将自己在商户a的积分兑换成在商户b的积分的业务。流程如下:(1)在积分pos机上刷客户的积分卡，选择兑换商户b积分，输入本次兑换要用去的商户a的积分额，积分pos将信息传送给积分系统;(2)积分系统核减数据库中该客户在商户a的积分余额，增加其在商户b的积分余额，记录交易流水并将可以进行兑换的确认信息回送至积分pos，交易完成;5. 积分查询积分查询是指客户通过积分pos机向积分系统查询在商户的积分余额的业务。流程如下:(1)客户在积分pos机上刷积分卡发起查询交易，积分pos机将信息传送给积分系统；(2)积分系统在数据库中提取客户积分余额返回给积分pos机，交易完成。6. 积分积累积分积累是指商户通过积分pos机把根据消费金额转化成的累计积分计入积分系统的业务。流程示意图如下:(1)商户由pos机发起积分积累请求，积分pos机将信息传送给积分系统;(2)积分系统按照商户设定的积累比率将消费金额计算为积分，完成积分累计。同时查询商户的奖励规则，若满足条件，则将客户获得奖励的确认消息发送回pos机。根据上述需求，可将业务处理系统的用例图3-3表示如下:图3.3客户积分系统业务处理系统用例图3.2.2积分业务管理系统积分业务管理系统是比较常见的web系统，主要用于系统管理员和商户管理员通过浏览器积分系统设置、查询数据等。具体功能包括:管理积分卡信息这个部分包括添加或修改积分卡以及积分卡用户的信息，包括卡号、密码、用户姓名、地址、性别、出生年日、电话等联系方式、用户等级等等。这些资料时系统实现积分奖励活动的基础资料。1.管理商户信息这个部分主要修改或添加积分系统的商户信息，包括商户功、商户名称、法人、联系人、地址、联系电话等。这是参加积分系统的所有商户资料。商户资料添加只能由系统管理员完成，商户只能修改自己的部分资料，如联系方式等。2.管理pos机及pos操作员信息这个部分主要包括商户联入系统的积分pos机和pos机操作员资料的添加和修改。这是pos机远程拨号进入系统时登陆验证的基础。这部分资料由商户管理。3.管理积分信息这个部分可以用来管理积分系统中的积分。通常积分的增减都是通过pos机上的交易完成，但也提供了这个管理功能，使商户在必要时可以调整自己所有积分卡的积分值。4.管理积分积累及奖励活动信息这个部分是客户积分系统的核心内容。商户点击连接进入的页面是根据登陆商户的不同而生成的动态页面，即每个商户正在运行的积分奖励规则是不同的。若商户随着时间或商品活动需要增加特殊的积分奖励规则时，开发人员可以对后台代码进行必要的调整，增加或调整奖励规则。5.综合查询及报表这个部分为商户提供了各种组合查询功能，同时可以根据查询结果生成积分结算和报表。商户可利用该查询获得消费者偏好、奖励活动效果等信息，从而相应设计、调整积分参数和比例，迎合不同消费者的喜好，迅速提高活动效果。6.管理系统信息这个部分设置和管理系统信息，包括运行状态、系统时间、各种系统全局参数等。7.管理系统用户这个部分只提供给系统管理员，主要用于添加和修改可登录系统的用户资料和权限。商户要登录系统，必须由系统管理员设置用户。根据上述需求，可将业务系统的用例图3-4表示如下:图3-4客户积分系统web管理系统用例图第四章 积分系统的具体实现4.1积分系统业务层的设计以及相关模式4.2.1业务层设计模式1.会话外观(session facade):外观模式的意图就是为子系统中的一组接口提供一个一致的界面，会话模式定义了一个高层接口，这个接口使得子系统更加容易使用。而利用会话外观模式，客户端访问会话外观来代替访问业务对象，当一个客户端需要调用多个业务对象的方法时，它只需要进行一次粗粒度的远程方法调用，将请求送给会话外观，再由会话外观通过本地方法调用，调用相应的业务对象，执行其方法。这样就减轻了网络负载，提高了系统性能。当业务对象的方法改动时，只需要修改会话外观，而客户端可以保持不变，这样不同的客户端可以采取不同的流程，这就减少了客户端和业务对象之间的藕合度，从而隐藏了实体bean交互的复杂性。同时客户端也不必管理事务的细节，而且当实体bean改变时，不用改变客户端的代码，只要对会话bean相应的改变即可，大大提高了系统的伸缩性和可维护性。下面是会话外观模式的好处:低网络开销。客户端能在一个网络调用中传输数据，而不是多次网络调用。在服务器上，会话bean和实体bean通过本地接口来调用，从而不会导致任何网络开销。严格的商业逻辑和表示层之间的分离。通过使用会话外观，需要去执行商业逻辑的逻辑完全被封装在会话外观的方法之后。e拍客户端无需关心表示层的事情，并且为了一个工作完成无需执行多于一个方法。这严格的将商业逻辑从表示逻辑分离。2.业务代理(business delegate):业务代理模式其实就是gof的proxy模式在ebj中的应用，它进一步降低了web层和ebj层之间的祸合，隐藏了业务逻辑调用的细节，如ebj的查找和访问的细节，也就是隐藏了远程性。该模式一般结合会话外观和服务定位器模式使用。即在业务代理里面通常利用服务定位器模式封装对会话外观的查找工作。它通常与会话外观存在一对一的关系，并向客户端提供了与会话外观相似的粗粒度接口。如果在业务代理存在调用多个e拍，那么就会把这些关系转移到相应的会话外观中。由此可见，使用业务代理可以进一步简化客户端代码的复杂程度。通过隐藏所有的业务层实现细节，业务代理会最大程度的降低表示层和业务层之间的藕合。由于只需要在业务代理一个地方进行变化的管理和维护，所以实现起来更加容易。使用业务代理的另一个好处是向客户端隐藏了远程性，也就是位置透明性。对客户端来说，它们可以不关心远程对象的具体位置，因为对远程对象的定位工作都被封装到业务代理里面去了。3.值对象(value object):值对象又称数据传输对象(data transfer object),也是基本设计之一，它使客户端能够和服务器端交换批量数据而不产生多个细粒度的远程网络调用。 这就要求有一种方法使客户端可以一次调用得到所需的大量数据，这种方法就是值对象模式。值对象是任意的可串行化的java对象，它在一次网络传输中包含和封装了大量的数据并被保存在内存中。当客户端需要再次使用数据的时候，不用再次到数据库中查询，而是直接在内存中读取值对象，节省了大量的时间和系统开销。 值对象可以同时在分布式系统中配合业务逻辑执行读操作和更新操作。当客户需要要更新服务器中的一些数据时，可以创建一个包装了所有服务器执行更新操作需要信息的值对象，然后送到服务器处理(通常是会话外观)。当然也可以通过使用许多细粒度参数调用的方式将数据传到服务器端，但这种方法不仅效率低，而且一旦有参数需要添加到方法中或者从方法中去处，那么涉及这些数据的所有方法都需要被更改。如果把参数封装到值对象中，那么只需要更改值对象本身就可以了。通常，值对象中的成员被定义为私有的，而其get/set方法则是公有的。也可以将值对象中的所有属性设置位公有的。有了值对象，客户端在需要传递数据时候，就把所有的数据打包在值对象中，然后通过网络发送到ejb层，经会话外观交给业务逻辑处理。同样当业务逻辑与客户端交互时，ebj层就会创建一个值对象来包装业务方法需要传递的数据，通过会话外观传递给客户端。 开始设计值对象的一种简单方法是将其设计为服务器端实体be的拷贝，又称为域值对象(domain value object)模式。这样在项目的初级设计阶段就可以建立可用的值对象，使开发可以迅速进行。然而，随着项目的进展，客户端的需求确定下来，域值对象对于某些数据请求来说显得过于笨重，粒度太大，无法满足客户端细粒度的要求。客户端可能仅仅需要访问某个实体bean中的某些属性，或者需要若干实体bena中的某几个属性的集合。在这种情况下，可以设计另一种灵活的值对象一自定值对象(customer value object)，也就是封装了任意数据集的值对象，这完全由客户端特定需求所驱动。4.值对象组装器(valuebojectassmebler):某些时候，直接映射数据库的值对象并不能很好的满足客户需要，因为有时客户端需要的可能是多个实体bean的信息，这时需要利用复合数值对象，用来包括客户端需要的全部信息。要实现这种特定的值对象，就可以应用值对象组装器。正确应用值对象组装器模式可以进一步减少远程的网络调用，它把对多个实体bean的访问合并到一个访问点。数值对象组装器使用值对象来组织客户所需数据。使用值对象组装器对数据进行进一步的组织，为系统的性能和维护带来很好处:提高了网络的性能，减少远程方法调用和会话的网络负担。客户端可以在单个远程调用后，得到数值对象组装器组装好的数据包。减少客户端复杂性，客户端可以将多个实体bean映射的数据作为一个数据集合来处理，不再需要复杂的访问和组织逻辑。进一步减少客户端和应用模型之间的藕合，因为值对象组装器对客户端隐藏了模型数据的复杂性和结构。如果数据模型发生变化，只需要更改值对象组装器的方法，客户端的代码不需要任何更改。分离了业务逻辑与客户端的联系，若客户端的业务逻辑发生变化，只影响之组装器的结构，可更改该模型的复合值对象，不影响客户端的逻辑结构。值对象组装器通常会以会话bean方式实现，在业务逻辑控制下以本地接口访问实体bean，获取必要数据，进行包装和组织，以值对象的结构传送至客户端。5.服务定位器(sevrieeloeoart):j2ee客户端与e用组件进行交互时，对于所有需要访问jndi管理的服务对象，都需要进行定位工作。也就是说，客户端必须定位(或称为查找)该服务组件，或创建一个新的组件。比如，ebj客户端必须定位ebj的本地对象，然后客户端使用该本地对象来查找、创建或删除一个或多个ejb。如果这些定位代码都写入在需要查找服务的客户端中，会导致不必要的重复现象。同时，创建最初刀叮dl环境和在ebj本地对象上执行查找都花费非大量的时间、占用大量的资源。通常应该缓存刀呵dl资源避免网络调用和某些处理的过载。可以缓存查找包括:ebjb home interfacesdata sourcesjms connection factoriesms destinations factories一些jndi包实现了缓存功能。但是调用对ebj主接口的narrow方法时，这作用有限。如果多个客户端反复地请求相同的bean本地对象，这种重复现象会响应用程序性能。使用服务定位器对象来抽取所有的jndl应用，并且隐蔽最初环境创建、ej对象查找和ebj对象重创建的复杂性。多个客户端可以重新使用服务定位器对象代码的复杂性，提供单控制点，并且通过提供缓冲机制来提高性能。该模式降低于客户端依赖性，提供了把所有依赖性和网络细节抽取到服务定位器的机制。4.22业务层的设计上面介绍了业务层的主要设计模式，通过正确应用这些模式，可以极大的提的灵活性、可维护性等性能。但仅仅了解设计模式的概念，不一定就能够设计出系统结构，还需要将模式的优缺点与系统自身的特点相结合，设计出与系统需求业务层结构。图4-1是积分系统业务层的一般结构:图4-1积分系统业务层的设计1.会话外观模式，是企业级应用的基础模式，但是千万不要以为外观模式就是简单的用会话bean把实体bean的所有方法统统封装起来，而不提供任何额外的抽象。其实这是对facade模式的滥用。这样做并不是降低整个系统的复杂性，而是把复杂性转移到另一个对象上。例如它常常被滥用为下列的情况:创建一个会话bean类。开发者把系统中所有的用例都放在一个会话bnae中。这导致臃肿的会话bean并降低开发生产力，因为所有的开发者都需要用这一个类。会话bean应该被分成相关用例的组群。所以要正确应用facade模式应遵循三条基本原则:它们自己不作实际工作，而是委派其他对象作实际工作。它们提供简单的接口。它们是底层系统的客户端接口。把特定于子系统的信息封装起来，并且不应该在不必要的情况下公开它。根据客户积分系统的需求，本系统的会话外观设计为七个:(1)pos业务处理模块(posfacdee):接受pos前置机发送来的数据，对数据进行实时处理，然后将处理结果打包成固定格式的数据包，并返回pos机。(2)积分卡处理模块(cardfacdae):包括添加或修改积分卡以及积分卡用户的详细资料。(3)商户处理模块(mefracdae):包括处理商户信息，处理商户所属pos机操作员信息。(4)积分处理模块(vaiuefacdae):用来管理积分系统中的积分。(5)处理积分积累及奖励活动信息(rewarfdacda)e:用来管理积分系统中的积分活动以及规则的设置。(6)系统管理模块(sysfacade):管理系统状态、信息，管理系统用户等。(7)综合查询(esarefhacdae):包括各种查询，同时可以实现报表功能。2. 会话外观在j2ee的设计中虽然不可或缺，但它使客户端与ebj层紧密的祸合，这样就形成了客户端与服务器端的依赖关系，这种依赖关系会影响到开发、运行时的系统复杂性。这时就需要利用业务代理来创建一个客户端和会话外观之间的中间构件来帮助把客户端从ebj层分离出来。业务代理其实是普通的java类，客户端调用业务代理的方法，该方法被代理给会话外观。在这种情况下，客户端代码都只和业务代理进行交互。业务代理还可以隐藏与ebj相关的系统异常。业务代理还有一个方便开发者的优点，就是提供了一种让程序员在没有会话外观，即业务逻辑模块的情况下，也能编写、编译、测试的方法。可以编写原型业务代理，它只是简单的返回模拟数据，或者在本地执行简单业务逻辑。当服务器端业务模块被构建好后，业务代理可以被重新修改以调用业务逻辑模块。业务代理模块通常与会话外观一一对应，可以在系统运行时将前端发来的客户请求代理给相应的会话外观。因此对应会话外观的设计，系统中包含七个业务代理模块:pos业务处理模块(posdeelgate)、积分卡处理模块(card delegate)、商户处理模块(merdelegate)、积分处理模块(valuedelegate)、处理积分积累及奖励活动信息(reward delegaet)、系统管理模块(sysnelegate)、综合查询模块(secarhdelegaet)。3.值对象也是系统中不可获缺的设计模式之一。它使客户端能够和服务器端交换批量数据而不产生多个细粒度的远程网络调用，大大提高网络调用效率。通过值对象组装器模式，可以根据系统功能需求，将实体bean包装成域值对象、自定义值对象或者复合值对象，进一步满足了客户端性能的要求，解除客户端与服务器端的藕合，降低客户端程序复杂度，分离业务逻辑。例如对于商户信息进行修改时，通常需要返回数据库商户资料表中所有字段的值，在这种情况下，可以直接应用域值对象，将cmp实体bean中的字段直接包装为值对象，并作为粗粒度数据返回客户端，供客户使用。而对于某些查询，客户在视图上需要的数据常常是几个数据库表联合后数据中的某些字段，为了保证传输的效率，我们使用自定义值对象，仅对查询需要的数据进行封装和传输。自定义值对象就像其它一般的值对象，区别在于它不映像到任何服务器端的数据结构。定制自定义值对象一般使用用例驱动的方法，即围绕客户端的需要来设计值对象。例如用户查询积分业务时，首先通常不需要获取全部信息，需要的是有关的积分额、业务种类的信息，所以我们把几个字段封装成一个自定义值对象(traction vo)。业务处理系统处理的数据都是固定数据包posdata(具体字段见4.6节)格式传输的，这种固定数据包简化了业务处理的复杂逻辑，在系统中也将实现为一种值对象。4.服务定位器是对zjee应用程序通过jndi查找并创建ejb等组件的公共代码的封装。除了减少代码的重复，更重要的是服务对象定位器采用了缓存技术，大大提高了应用程序的性能。在客户积分系统中，很多资源和对象包括大量的会话bena和实体bena的获取，都要经过jndi的查找和定位。所以代码中不可避免的要出现很多具有定位功能的语句。例如在客户积分系统中，当在具体业务代理中访问会话外观时，首先要通过jndi定位会话外观。这些代码如果分散在应用程序的各个地方，不但影响了程序的可读性、可维护性，更为重要的是，在不同地方的多次定位相同对象严重降低了系统的性能。因此，在本系统中，我们将ebj本地接口、数据库联接等资源的访问都包装到数据定位器中，尽量应用系统的定位缓存提高系统性能。业务层实际上并不直接与数据库中的数据发生交互，而是通过数据访问对象设计模式来完成最终的数据访问和处理。有关数据访问设计模式，将在.43.1节中详细介绍。4.2.3业务层优化策略实际上应用上面提到的设计模式，就是对系统的一种优化。同时，根据.net技术的特点，适当选择.net组件，充分利用服务器对组件的支持，微调组件实现方式等，都可以使系统的结构更适合实际需求。1.充分使用无状态会话bean使用无状态会话bean，而不是有状态会话bean。这样做可以使系统经得起错误的终止。从某种的观点看来，有状态会话bean的概念己经过时了。一个有状态会话bean实际上与一个corba对象在体系结构上是完全相同的，是一个对象实例绑定到服务器，并且依赖服务器来管理其生命周期。如果服务器关闭了，这种对象也就不存在，那么这个bean的客户端的信息也就不存在。.net应用服务器为有状态会话bean提供的故障转移能够解决一些问题，但是有状态的解决方案没有无状态的解决方案易于扩展。例如，在web spheer applicatino server中，对无状态会话bean的请求是通过对部署无状态会话的成员集群进行平衡加载来实现。相反地，zjee应用服务器不能对有状态bean的请求进行平衡加载。这意味着集群中服务器的加载过程会是不均衡的。此外，使用有状态会话bean将会再添加一些状态到应用服务器上，这也是不好的做法。这样就增加了系统的复杂性，并且在出现故障的情况下使问题变得复杂化。创建健壮的分布式系统的一个关键原则是尽量使用无状态行为。因此，应该对大多数应用程序使用无状态会话b哪方法。任何在处理时需要使用的与用户相关的状态应该以参数的形式传送到ejb的方法中，或者从持久性的后端存储中进行检索。这个信息可以缓存到内存中，但是要注意在分布式的环境中保存这种缓存所潜在的挑战性，缓存非常适合于只读数据。总之，考虑到系统的可伸展性，在积分系统中避免使用有状态会话bean是一个基本的设计原则。2.cmp实体bena作为首选方案对象关系映射是创建企业级的应用程序的基础。几乎每个应用程序都需要一些类型的o瓜映射。厂商提供一种o/r映射机制，这种机制在不同的厂商间是可移植的、高效的，并且能够被一些标准及工具很好地支持。这就是ebj规范中的cmp(容器管理的持久性)部分。早期的cmp实现以表现不佳以及不支持许多sql结构而著称。然而，随着ebj2.0及2.1规范的出现，已经被一些厂商所采纳，并且随着像ibm wbesphere studio appliaction developer等开发平台的出现，这些问题已经得到了很好的解决。设计开发时，首先为数据库中的每个表创建一个实体bean，然后映射为cmp模式。使用cmp的好处在于容器提供公共的服务，例如目录服务、事务管理、安全性、持久性、资源缓冲池以及容错性等，使开发人员不必维护将会集成到业务逻辑中的系统级代码，只需专注于商业逻辑。与bmp相比，cmp提供了跨多种不同数据库的可移植性，因为cmp实体bena不包含任何特定于数据库的持久性代码，所以cmp易于设计、实现和维护。而且在通常情况下，cmp拥有好于bmp的性能，因为ebj容器将自动生成特定于数据库的代码，并且这些代码将为目标数据库而优化。cmp ebj组件现在已经被广泛地应用于许多高性能的应用程序中。例如客户积分系统将采用的webspheer服务器包括的一些优化功能来提高ebj组件的性能。优化功能包括:对生命周期的缓存和read-ahead能力。这两者优化功能都是配置时的选项，并且不需要对应用程序进行修改或者影响可移植性。从处于缓存状态的生命周期得到的性能提高可以达到很好的性能，并且提供良好的可伸展性。例如cmp中实现的finder方法，可以在一次数据库访问中缓存所有查找到的记录，不会造成+n1次数据库读取的性能损失。当然cmp的方便也带来了开发灵活性的降低，为了提高只读应用的性能，可以结合快速信道读取器(fast-lane reader)模式。3.为实体bena确定主键类无论在永久性存储还是e工b容器之内，ebj主键类都起着唯一标识符的作用。主键类的域常常直接映射到数据库的主键字段。如果主键只是一个单一的实体bean域，而且它属于java简单数据类型(比如java.lang.string)，那么，bean开发者无需编写定制的主键类，开发者只需在部署描述器中指定类的名字和主键域的名字。主键类包含主键域，主键域必须是public类型。另外，主键类还必须包含一个没有参数的构造函数。主键类必须实现hash code和euqals方法。ejb容器内部要用到大量的数据结构，其中许多都通过主键类索引。因此，对于主键类来说，正确、高效地实现这两个方法是至关重要的。在设计数据库时，我们可以选用卡号、商户代码等具有自然意义的字段单独或者组合作为主键，当这并不是一种有效的设计方法。因为这种字段虽然具有很好的确定唯一记录的功能，但本身的值会随着时间发生改变，非常不利于数据库的检索。相比之下，如果使用一个简单的递增数字作为主键将是一种非常高效，并且具有很高的可维护性的方法。因为相比巨大的基于字符串，整数可以被更容易而且更高效的索引。当然，这也带来另外一个问题，即如何实现具有可以执行的实体bnae主键生成方法。分析各种主键生成策略，在客户积分系统中将采用序列块的方法来为实体bean生成唯一确定的主键。简单的说，这种方法就是在序列实体bean之前设置一个会话bean，这个会话bena在某个时刻获得整数块并把它们缓存在本地。客户端与这个会话bean进行交互，会话bean把缓存的键传递出去并对其它的实体bean客户端隐藏所有的复杂性。这种方法不仅具有很好的可扩展性、可重用性，还具有很好的性能，因为一次数据库读取，就可以生成多个唯一的主键值。4.消息驱动bean的使用ejb.zo的规范中定义了一个新的ejb组件，目的是用于接收异步的消息。它实现了多种“异步ebj组件方法调用”机制。客户积分系统的业务处理部分需要接受pos机发送的数据并实时进行处理，消息驱动bean为提高系统处理速度提供了一种很好的方法。从用例的角度来说，pos机业务的请求是同步的，因为客户需要系统返回合适的数据，但从更细的粒度来分析，还是会找到一些可用异步来执行的操作。例如对于积分业务处理系统的“积分兑换服务”功能，按照图3.2的流程，其中第(2a)操作要求将服务开通通知信息发送给服务提供商户业务主机，这个工作就可以由消息驱动bean实现。如果系统检查用户的兑换请求可以通过，则发送一个jms消息，其中包括兑换服务种类和用户标识。这个mjs消息并不会直接发送给服务提供商的系统，而是发送给一个消息驱动bean(open service)，由它来异步的开通服务。还有一个可以异步执行的操作是对业务流水表的记录。除了查询的操作以外，用户的所有请求，不管实现与否都应该被记录到系统的流水表中，以供日后统计和分析。这个工作跟用户当前的操作关系不大，用户并不需要知道对流水表的记录是否成功，那么就可以在处理完用户关心的业务逻辑以后，将需要记入流水的数据以mjs消息的方式发送到合适的目的地，然后由后台的消息驱动bnae(serialrec)去处理。消息发送以后，服务器即可将用户需要的数据返回pos机，加快了系统对用户的响应速度。根据上面的分析，得到客户积分系统业务层的详细设计图4-2:图4-2积分系统业务层的设计这种设计结构，充分利用了各个设计模式的优点，使积分系统业务层与客户端、数据库的祸合性降到最小，使系统地维护性和灵活性大大提高。同时还考虑到.net技术的特点，提高了系统的运行性能、事务安全等特性。4.4积分系统业务逻辑的详细设计前文从系统结构角度分析和设计了客户积分系统的结构，为系统可复用性、可扩展性、可维护性的增强奠定了坚实的基础。除了系统的体系结构外，客户积分系统的业务逻辑的设计也非常重要，它们是系统能够正确有效完成业务处理的根本。对于积分管理部分(web维护)，系统主要完成对数据库中的商户数据、积分数据、操作员数据、活动数据的检索、更新、添加等操作，属于比较常见的web业务逻辑。又因为客户积分系统的大部分实体bean均采用cmp实体bean来实现，因此对数据的访问和处理由j2ee的容器来协助完成，所以对开发人员在业务逻辑方面要求不高。此外，对于这些业务逻辑结构的设计，可以借鉴前人的成熟经验，灵活正确应用基本设计模式，就会得到比较有效的结构，然后在这个基础上根据系统需求进行进一步的优化和调整。对于积分业务处理系统(pos机交互)，大多数工作也是根据pos机数据包(posdaat)中的相应数据，对数据库进行读取和修改的操作。在设计的过程中，特别需要注重系统的实时性能。在这些业务逻辑中，商户积分奖励活动规则是一个比较重要的需求。它主要对posdata的数据按照商户设定好的规则进行检测，并将积分卡用户的获奖结构返回pos机。这个业务逻辑在系统运行过程中变动性很大，因此对结构的可扩展性要求较高。同时也需要关注系统的实时性能。因此，下面以商户积分奖励活动规则为例，基于基本模式设计客户积分系统的业务逻辑结构。下文首先介绍在设计积分奖励规则模块中用到的设计模式，然后将这两种设计模式结合起来，实现积分奖励规则的逻辑结构。4.4.1相关设计模式1.策略模式:策略模式是属于设计模式中对象行为型模式，其中体现了两个非常基本的面向对象设计的基本原则:封装变化的概念，编程中使用接口，而不是对接口实现。策略模式的定义如下:定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式使这些算法在客户端调用时能够互不影响地变化。策略模式在实际中应用比较广泛。比如公司经营业务变化图，可能有两种实现方式，一个是线条曲线，一个是框图(bar)，这是两种算法，可以使用strategy实现。策略模式使开发人员能够开发出由许多可替换的部分组成的软件，并且各个部分之间是弱连接的关系。弱连接的特性使软件具有更强的可扩展性，易于维护。更重要的是，它大大提高了软件的可重用性。通过策略，可以达到使系统在运行期间自由切换算法的目的。实际整个策略的核心部分就是抽象类的使用，使用策略模式可以在用户需要变化时的代码修改量减小，而且维护速度快。strategy适合下列场合:(1)以不同的格式保存文件;(2)以不同的算法处理文件;于(3)以不同的算法截获图象;(4)以不同的格式输出同样数据的图形等2.职责链(chain of responsibiliyt)模式:职责链是用一系列类试图处理一个请求，这些类之间是一种松散藕合，唯一共同点是在它们之间传递请求。也就是说，来了一个请求，第一个类先处理，如果没有处理，就传递到第二个类处理，如果没有处理，就传递到下一个类处理，就这样象一个链条一样传递下去。一般说来，实现职责链的模式，有几个要点:每个对象中的代码，能够指出它要转发的对象，并能够说明自己是不是涟中的最后一个对象，但这个指定不是由对象本身来自己指定，而是给出一个接口，由外部的实体来指定。有专门的类中，将各个对象链接起来。有发送信息的入口。职责链模式的使用，一般针对的情况:1.发送一条消息，但只要求对象处理消息是有次序的，并且只要有对象处理这个消息时就中止。2、发送一条消息，并不知道究竟有一个还是多个对象需要处理该消息。这时，就可以设计一个入口点，让这些不确定哪些才会响应消息的对象形成一个链条，然后让它们自己来判断是否响应消息。例如，制定了一个业务流程，然后程序都是按此业务流程办理，但需求突然变更了，客户调整了处理流程(修改了资料或添加了新的流程)，要求程序要相应的更改。此时，如果业务流程中的消息传递是采用职责链来完成的，那么只