毕业设计(论文)-基于NHibernate的CRM系统.doc_第1页
毕业设计(论文)-基于NHibernate的CRM系统.doc_第2页
毕业设计(论文)-基于NHibernate的CRM系统.doc_第3页
毕业设计(论文)-基于NHibernate的CRM系统.doc_第4页
毕业设计(论文)-基于NHibernate的CRM系统.doc_第5页
已阅读5页,还剩58页未读 继续免费阅读

下载本文档

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

文档简介

基于NHibernate的CRM系统摘 要信息时代的到来让人类开始进入一个新的纪元,越来越多的人开始在生活、学习、工作中运用电脑。客户关系管理是一个企业不可缺少的部分,它的内容对于公司的实施部和管理者来说都至关重要,所以客户信息系统应该能够为用户提供充足的信息和快捷的查询方式。但是一直以来人们都没有好的方式来对管理客户的信息进行系统、全面的管理,这样存在着很多缺点:效率低、容易忘记、容易失去老客户等。用计算机制作的客户信息管理系统可以通过功能强大的Internet网及时的向公司的实施部、客户人员,及公司管理层提供客户的详、全面的信息,有助于企业和客户保持良好关系,更能使企业与一些老客户能保持长期合作。好地把握企业的业务走向!因此,开发这样一套管理软件成为很有必要的事情。客户信息管理系统是基于三层体系结构的开发,项目采用B/S模式,以ASP.NET2.0开发背景,数据库系统采用SQLServer2005,本系统使用C#作为开发语言。同时在项目中运用到技术有三层体系结构、存储过程、Session、NHibernate等。客户信息管理在经历需求分析、编码、测试到最后项目的完成;本系统主要功能有:客户数据、导入/导出数据、网上采集客户、任务计划、账户管理等功能。我在些当中学习很多知识,项目很有可能存在局限性及存在着某些功能方面上的不足。关键字:客户关系管理系统、面向对象、三层体系结构、存储过程、NHibernate第一章 引言 1.1课题的背景在信息化的时代,对于客户的关系管理一直是企业的一件头疼的事情。因为不论是中小型企业还是大型企业都面对着客户的信息管理。客户是企业的生命源泉。所以对客户的信息公司要尽可能掌握到越详细越好。对公司的业务发展有着巨大的作用。在客户信息管理系统的开发过程中,采用了面向对象技术和三层架构的模式来进行系统的分析与设计。三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。本系统运用了NHibernate技术,使系统在编码的过程中减少了很多工作量,提高开发速度。系统在数据库方面使用视图、存储过程来提高系统的性能。 1.2研究意义本论文的主要工作分为三个阶段:第一阶段:阅读参考文献和书籍,深入理解和掌握三层架构及NHibernate技术,并学习使用对象、接口、抽象。第二阶段:对项目进行分析,进行需求分析建模、系统分析建模、系统设计建模,数据库建模,并参与项目的部分功能模块的开发。第三阶段:整理相关资料,撰写论文。第二章 CRM 2.1 CRM简介CRM(Customer Relationship Management),即客户关系管理。这个概念最初由Gartner Group提出来,而在最近开始在企业电子商务中流行。CRM的主要含义就是通过对客户详细资料的深入分析,来提高客户满意程度,从而提高企业的竞争力的 一种手段。企业用CRM来管理与客户之间的关系。CRM是选择和管理有价值客户及其关系的一种商业策略,CRM要求以客户为中心的商业哲学和企业文化来支持有效的市场营销、销售与服务流程。如果企业拥有正确的领导、策略和企业文化,CRM应用将为企业实现有效的客户关系管理。CRM是一个获取、保持和增加可获利客户的方法和过程。CRM既是一种崭新的、国际领先的、以客户为中心的企业管理理论、商业理念和商业运作模式,也是一种以信息技术为手段、有效提高企业收益、客户满意度、雇员生产力的具体软件和实现方法。通过了解哲学、文学和美学领域较早提出的“以接受者为中心”思想,有助于您进一步理解经济学“以 客户为中心”的概念。惠子讲:“子非鱼,安知鱼之乐”你不是鱼,你怎么知道鱼快乐不快乐。如果能够准确把握住接受者的体验,这个人不成为大富豪,也会 成为大思想家。接受美学是汉斯.罗伯特.姚斯(HansRobertJauss)于1967年创立的以往的文学和美学研究、创作,都是以作者/艺术家 为中心,姚斯则主张根本性地、颠覆地转向以读者/接受者为中心,因此称作接受美学。它相当于经济学“以产品/厂商为中心”向“以客户为中心”的转变,姚斯 的“读者/接受者中心论”体验理论比托夫勒预言的体验经济早了三年,比菲利普.科特勒完善的“4C”理论早了更多年“4C”是后来CRM客户关系管理出台并走向成熟的理论源泉之一。CRM 最大程度地改善、提高了整个客户关系生命周期的绩效。CRM整合了客户、公司、员工等资源,对资源有效地、结构化地进行分配和重组,便于在整个客户关系生 命周期内及时了解、使用有关资源和知识;简化、优化了各项业务流程,使得公司和员工在销售、服务、市场营销活动中,能够把注意力集中到改善客户关系、提升 绩效的重要方面与核心业务上,提高员工对客户的快速反应和反馈能力;也为客户带来了便利,客户能够根据需求迅速获得个性化的产品、方案和服务。 2.2 CRM体系结构客户概况分析(Profiling)包括客户的层次、风险、爱好、习惯等; 客户忠诚度分析(Persistency)指客户对某个产品或商业机构的忠实程度、持久性、变动情况等; 客户利润分析(Profitability)指不同客户所消费的产品的边缘利润、总利润额、净利润等; 客户性能分析(Performance)指不同客户所消费的产品按种类、渠道、销售地点等指标划分的销售额; CRM功能客户未来分析(Prospecting)包括客户数量、类别等情况的未来发展趋势、争取客户的手段等; 客户产品分析(Product)包括产品设计、关联性、供应链等; 客户促销分析(Promotion)包括广告、宣传等促销活动的管理。 它不仅仅是一个软件,它是方法论、软件和IT能力综合,是商业策略。 在不同场合下,CRM可能是一个管理学术语,可能是一个软件系统,而通常我们所指的CRM,是 指用计算机自动化分析销售、市场营销、客户服务以及应用支持等流程的软件系统。它的目标是缩减销售周期和销售成本、增加收入、寻找扩展业务所需的新的市场 和渠道以及提高客户的价值、满意度、赢利性和忠实度。 CRM项目的实施可以分为3步,即应用业务集成,业务数据分析和决策执行。 应用业务集成。将独立的市场管理,销售管理与售后服务进行集成,提供统一的运作平台。将多渠道来源的数据进行整合,实现业务数据的集成与共享。这一环节的实现,使系统使用者可以在系统内得到各类数据的忠实记录,代表目前真实发生的业务状况。 业务数据分析。对CRM系统中的数据进行加工、处理与分析将使企业受益匪浅。对数据的分析可以采用OLAP的方式进行,生成各类报告;也可以采用业务数据仓库(Business Information Warehouse)的处理手段,对数据做进一步的加工与数据挖掘,分析各数据指标间的关联关系,建立关联性的数据模型用于模拟和预测。这一步所取得的结果将是非常重要的,它不单反映业务目前状况同时也对未来业务计划的调整起到指导作用。 决策执行。依据数据分析所提供的可预见性的分析报告,企业可以将在业务过程中所学到的知识加以总结利用,对业务过程和业务计划等做出调整。通过调整达到增强与客户之间的联系,使业务运作更适应市场要求的目的。 在传统企业引入电子商务后,企业关注的重点由提高内部效率向尊重外部客户转移。而CRM理念正是基于对客户的尊重,要求企业完整地认识整个客户生命周期,提供与客户沟通的统一平台,提高员工与客户接触的效率和客户反馈率。一个成功的客户关系管理系统至 少应包括如下功能:通过电话、传真、网络、移动通讯工具、电子邮件等多种渠道与客户保持沟通;使企业员工全面了解客户关系,根据客户需求进行交易,记录获 得的客户信息,在企业内部做到客户信息共享;对市场计划进行整体规划和评估;对各种销售活动进行跟踪;通过大量积累的动态资料,对市场和销售进行全面分 析。实施CRM时候要注意一点,就是要设置好收集信息的机制,要收集有用的客户资料和信息,对于无用的信息则要丢弃。第三章 NHibernate 3.1 NHibernate简介NHibernate是一个面向.NET环境的对象/关系数据库映射工具。对象/关系数据库映射(object/relational mapping (ORM)这个术语表示一种技术,用来把对象模型表示的对象映射到基于SQL的关系模型数据结构中去。 NHibernate不仅仅管理.NET类到数据库表的映射(包括.NET数据类型到SQL数据类型的映射),还提供数据查询和获取数据的方法,可以大幅度减少开发时人工使用SQL和ADO.NET处理数据的时间。 NHibernate的目标是对于开发者通常的数据持久化相关的编程任务,解放其中的95%。对于以数据为中心的程序来说,它们往往只在数据库中使用存储过程来实现商业逻辑,NHibernate可能不是最好的解决方案;对于那些在基于.NET的中间层应用中,它们实现面向对象的业务模型和商业逻辑的应用,NHibernate是最有用的。不管怎样,NHibernate一定可以帮助你消除或者包装那些针对特定厂商的SQL代码,并且帮你把结果集从表格式的表示形式转换到一系列的对象去。 3.2 NHbernate体系结构 3.2.1概况(Overview)一个非常简要的NHibernate体系结构的概要图: 图3-1从这个图可以看出,NHibernate使用数据库和配置信息来为应用程序提供持久化服务(以及持久的对象)。 我们来更详细地看一下NHibernate运行时体系结构。由于NHibernate非常灵活,且支持多种应用方案, 所以我们这只描述一下两种极端的情况。“轻型”的体系结构方案,要求应用程序提供自己的ADO.NET 连接并管理自己的事务。这种方案使用了NHibernate API的最小子集:图3-2“全面解决”的体系结构方案,将应用层从底层的ADO.NET API中抽象出来,而让NHibernate来处理这些细节。 图3-3图中各个对象的定义如下: ISessionFactory (NHibernate.ISessionFactory) 针对单个数据库映射关系经过编译后的内存镜像,是线程安全的(不可变)。 它是生成ISession的工厂,本身要用到IConnectionProvider。 该对象可以在进程或集群的级别上,为那些事务之间可以重用的数据提供可选的二级缓存。 ISession (NHibernate.ISession) 表示应用程序与持久储存层之间交互操作的一个单线程对象,此对象生存期很短。 其隐藏了ADO.NET连接,也是 ITransaction的工厂。 其会持有一个针对持久化对象的必选(第一级)缓存, 在遍历对象图或者根据持久化标识查找对象时会用到。 持久的对象及其集合(Persistent Objects and Collections) 带有持久化状态的、具有业务功能的单线程对象,此对象生存期很短。 这些对象可能是普通的POCOs, 唯一特殊的是他们正与(仅仅一个)ISession相关联。 一旦这个ISession被关闭, 这些对象就会脱离持久化状态,这样就可被应用程序的任何层自由使用。 (例如,用作跟表示层打交道的数据传输对象。) 瞬态(transient)和脱管(detached)的对象及其集合 那些目前没有与ISession关联的持久化类实例。 他们可能是在被应用程序实例化后, 尚未进行持久化的对象。 也可能是因为实例化他们的ISession已经被关闭而脱离持久化的对象。 ITransaction (NHibernate.ITransaction) (可选的)应用程序用来指定原子操作单元范围的对象,它是单线程的,生命周期很短。 它通过抽象将应用从底层具体的ADO.NET事务隔离开。 某些情况下,一个ISession之内可能包含多个ITransaction对象。 IConnectionProvider (NHibernate.Connection.IConnectionProvider) (可选的)生成ADO.NET连接以及Command对象的工厂。 它通过抽象将应用从底层的IDbConnection或IDbCommand隔离开。 仅供开发者扩展/实现用,并不暴露给应用程序使用。 IDriver (NHibernate.Driver.IDriver) (可选的)一个封装了不同ADO.NET providers之间的差异(利用参数命名转换等ADO.NET支持的特性)的接口。 ITransactionFactory (NHibernate.Transaction.ITransactionFactory) (可选的)生成ITransaction对象实例的工厂。 仅供开发者扩展/实现用,并不暴露给应用程序使用。 在特定“轻型”的体系结构中,应用程序可能绕过 ITransaction/ITransactionFactory 以及 IConnectionProvider 等API直接跟ADO.NET打交道。 3.2.2实例状态一个持久化类的实例可能处于三种不同状态中的某一种。 这三种状态的定义则与所谓的持久化上下文(persistence context)有关。 NHibernate的ISession对象就是这个所谓的持久化上下文: 瞬态(transient) 该实例从未与任何持久化上下文关联过。它没有持久化标识(相当于主键值)。 持久化(persistent) 实例目前与某个持久化上下文有关联。 它拥有持久化标识(相当于主键值),并且可能在数据库中有一个对应的行。 对于某一个特定的持久化上下文,NHibernate保证持久化标识与CLR标识(其值代表对象在内存中的位置)等价。 脱管(detached) 实例曾经与某个持久化上下文发生过关联,不过那个上下文被关闭了, 或者这个实例是被序列化(serialize)到另外的进程。 它拥有持久化标识,并且在数据库中可能存在一个对应的行。 对于脱管状态的实例,NHibernate不保证任何持久化标识和CLR标识的关系。 3.2.3上下文相关的(Contextual)Session使用NHibernate的大多数应用程序需要某种形式的“上下文相关的” session,特定的session在整个特定的上下文范围内始终有效。 然而,对不同类型的应用程序而言,要为什么是组成这种“上下文”下一个定义通常是困难的;不同的上下文对“当前”这个概念定义了不同的范围。 从1.2版本开始,NHibernate增加了ISessionFactory.GetCurrentSession()方法,ISessionFactory.GetCurrentSession()的后台实现是可拔插的。 因此,我们引入了新的扩展接口(NHibernate.Context.ICurrentSessionContext)和新的配置参数(hibernate.current_session_context_class), 以便对什么是“当前session”的范围和上下文(scope and context)的进行可拔插式定义。 请参阅NHibernate.Context.ICurrentSessionContext接口的API文档,那里有关于它的契约的详细讨论。 它定义了单一的方法,CurrentSession(),特定的实现用它来负责跟踪当前的上下文session。NHibernate 2.0.0内置了此接口的以下几种实现。 NHibernate.Context.ManagedWebSessionContext - 当前session保存在HttpContext之中。 但是,你必须自己通过CurrentSessionContext类中的静态方法手动的把ISession实例绑定或者取消绑定到当前上下文, ISession自己不会打开创建、清楚、或者关闭。 NHibernate.Context.CallSessionContext - 当前session保存在CallContext. 你必须自己通过CurrentSessionContext类中的静态方法手动的把ISession实例绑定或者取消绑定到当前上下文。NHibernate.Context.ThreadStaticSessionContext - 当前session保存在Thread Static变量。这个上下文只支持一个ISessionFactory. 你必须自己通过CurrentSessionContext类中的静态方法手动的把ISession实例绑定或者取消绑定到当前上下文, NHibernate.Context.WebSessionContext - 和上面的ManagedWebSessionContext类似, 当前session保存在HttpContext之中。 但是,你必须自己通过CurrentSessionContext类中的静态方法手动的把ISession实例绑定或者取消绑定到当前上下文, hibernate.current_session_context_class配置参数定义了应该采用哪个NHibernate.Context.ICurrentSessionContext 实现。一般而言,此参数的值指明了要使用的实现类的全名,但那三种内置的实现可以使用简写,即managed_web, call,thread_static, and web。第四章 多层架构 4.1 二层体系结构传统的二层体系结构是C/S结构,即Client/Server(客户机服务器)结构,这一概念最早用于描述软件的体系结构,表示两个程序间的关系,一个是提出请求的应用程序,另一个是服务程序。从概念上讲,C/S模式是一种特殊的协作处理模式,整个应用程序分布于客户机和服务器上,两者都参与一个应用程序的处理。C/S模式把系统分成两个基本组成部分:客户机(Client):面向最终用户,实现各自业务处理、提供人机交互界面;服务器(Server):负责有效地管理系统资源,并提供某项服务功能。C/S模型方案中客户应用程序向服务器程序请求服务。这种方式隐含了在建立客户机/服务器间通讯时的非对称性。客户机/服务器模型工作时要求有一套为客户机和服务器所共识的惯例来保证服务能够被提供(或被接受)。这一套惯例包含了一套协议。它必须在通讯的两头都被实现。根据不同的实际情况,协议可能是对称的或是非对称的。在对称的协议中,每一方都有可能扮演主从角色;在非对称协议中,一方被不可改变地认为是主机,而另一方则是从机。一个对称协议的例子是Internet中用于终端仿真的TELNET。而非对称协议的例子是Internet中的FTP。无论具体的协议是对称的或是非对称的,当服务被提供时必然存在“客户进程”和“服务进程”。一个服务程序通常在一个众所周知的地址监听对服务的请求,也就是说,服务进程一直处于休眠状态,直到一个客户对这个服务的地址提出了连接请求。在这个时刻,服务程序被“惊醒”并且为客户提供服务一对客户的请求作出适当的反应。这一请求/相应的过程如图2-1所示。虽然基于连接的服务是设计客户机/服务器应用程序时的标准,但有些服务也是可以通过数据报套接口提供的。图4-1 客户端/服务器的结构 4.2 三层体系结构的简介 4.2.1 三层体系结构的由来C/S软件体系结构,即Client/Server (客户机/服务器)结构,是基于资源不对等,且为实现共享而提出来的,是20世纪90年代成熟起来的技术,C/S结构将应用一分为二,服务器(后台)负责数据管理,客户机(前台)完成与用户的交互任务。C/S 体系结构具有强大的数据操作和事务处理能力,模型思想简单,易于人们理解和接受。但随着企业规模的日益扩大,软件的复杂程度不断提高,传统的二层C/S结构存在以下几个局限:(1)在传统的二层C/S结构数据库应用中,客户端的机器执行应用程序,连接到后端的数据库服务器中存取应用系统所需资料,因为应用系统的企业逻辑都编写在客户端的应用程序中,造成客户端非常臃肿,且当应用系统需求改变时,所有在客户端的应用程序都必须改变,使维护成本太高;(2)二层C/S结构是单一服务器且以局域网为中心的,所以难以扩展至大型企业广域网或Internet;(3)软、硬件的组合及集成能力有限;(4)客户机的负荷太重,难以管理大量的客户机,系统的性能容易变坏;(5)数据的完整性与安全性难以维护。因为众多客户端程序可以直接访问数据库服务器,那么,在客户端计算机上的其他程序也可想办法访问数据库服务器,从而使数据库的安全性受到威胁。正是因为二层C/S有这么多缺点,因此,三层体系结构应运而生。 4.2.2 三层体系结构的原理为提高数据的安全性与系统的可扩充性,可在两层模型的基础上考虑采用三层(3-tier)设计模型,将数据库访问分布在一个中间层。客户程序与数据库的连接被中间层屏蔽,客户程序只能通过中间层间接地访问数据库。中间层可能运行在不同于客户机的其它机器上,经过合理的任务划分与物理部署后,可使得整个系统的工作负载更趋均衡,从而提高整个系统的运行效率。这些位于中间层的程序又称应用服务程序(Application Server),因为它们实际上表达了一个企业处理信息的主要业务逻辑(Business Logic),即企业的系统模型与功能模型,而客户程序仅实现图形用户界面,完成终端用户与业务逻辑之间的交互。从客户程序的角度来看,中间层将企业的所有业务逻辑抽象为更高层次的应用程序接口(API),客户程序则通过这些API构建整个企业的应用系统。与典型的两层模型相比,三层模型可更好地支持对企业业务逻辑的集中控制与管理。三层结构应用软件与传统的C/S模式下的两层结构应用软件相比,有着可伸缩性好、可管理性强、安全性高、软件重用性好以及节省开发时间等诸多优点。在Internet/Intranet环境下,这些优点显得更加突出。很多公司也提出了三层应用软件体系结构。三层结构的客户/服务器模型是一种先进的协同应用程序开发模型,这种方案将客户/服务器系统中各种各样的部件划分为三层服务,它们共同组成一个应用程序,这三层服务包括: 客户端服务程序,称为表示层; 业务服务和其它中间层服务程序,通常称为业务逻辑层(中间层);数据层(数据库)。典型的三层结构如图2-2所示。图4-2 典型的三层结构表示层是应用的用户接口部分,它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据,显示应用输出的数据。为使用户能直观地进行操作,一般要使用图形用户接口,操作简单、易学易用。在变更用户接口时,只需改写显示控制和数据检查程序,而不影响其他两层。检查的内容也只限于数据的形式和取值的范围,不包括有关业务本身的处理逻辑。功能层相当于应用的本体,它是将具体的业务处理逻辑编入程序中。例如,在制作订购合同时要计算合同金额,按照定好的格式配置数据、打印订购合同,而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。例如,用户检索数据时,要设法将有关检索要求的信息一次性地传送给功能层,而由功能层处理过的检索结果数据也一次性地传送给表示层。通常,在功能层中包含有确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。功能层的程序多半是用可视化编程工具开发的,也有使用COBOL和C语言的。数据层就是数据库管理系统,负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此,一般从功能层传送到数据层的要求大都使用SQL语言。这些层次并不一定与网络上的具体物理位置相对应,它们只是概念上的层,借助这些概念可以开发出强大的应用程序。使用这种方法设计应用程序,开发人员在网络上部署进程及数据时可以有相当大的灵活性,从而有利于实现最佳的性能、更好的安全性以及更方便的维护。中间层中包括提供业务服务和其它中间服务的部件,是联系用户服务和数据服务的桥梁,它们响应用户(或其它业务服务)发来的请求,执行某种业务任务,并对相应的数据进行处理。用户不需要直接与数据库打交道。在实际应用过程中,中间层部件通常可分为两个以上的层次。因此,该应用模型也被称为多层次结构。三层体系结构的解决方案是:对这三层进行明确分割,并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来,所以,关键是要将表示层和功能层分离成各自独立的程序,并且还要使这两层间的接口简洁明了。如果将功能层和数据层分别放在不同的服务器中,则服务器和服务器之间也要进行数据传送。但是,由于在这种形态中三层是分别放在各自不同的硬件系统上的,所以灵活性很高,能够适应客户机数目的增加和处理负荷的变动。例如,在追加新业务处理时,可以相应增加装载功能层的服务器。因此,系统规模越大这种形态的优点就越显著。在更复杂的多层体系结构中,客户与远程数据库服务器之间可以加入更多的中间服务器,如加入一个中间安全服务器或中间转换服务器,用于对不同平台数据进行处理。分布式多层结构把整个应用系统的执行分成数个不同部分并且执行在不同的机器中。其中应用程序服务器作为中间层集中实现企业逻辑,协调多层之间的请求,并掌握数据集定义的全部细节和远程数据库服务器进行通信,这样客户端应用程序就重点放在显示数据和与用户交互上,客户端应用程序甚至都不需要知道数据在那儿。 4.2.3 三层体系结构的特点三层体系结构具有以下特点: (1)允许合理地划分三层的功能,使之在逻辑上保持相对独立性,从而使整个系统的逻辑结构更为清晰,能提高系统和软件的可维护性和可扩展性。(2)允许更灵活有效地选用相应的平台和硬件系统,使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层;并且这些平台和各个组成部分可以具有良好的可升级性和开放性。例如,最初用一台Unix工作站作为服务器,将数据层和功能层都配置在这台服务器上。随着业务的发展,用户数和数据量逐渐增加,这时,就可以将Unix工作站作为功能层的专用服务器,另外追加一台专用于数据层的服务器。若业务进一步扩大,用户数进一步增加,则可以继续增加功能层的服务器数目,用以分割数据库。清晰、合理地分割三层结构并使其独立,可以使系统构成的变更非常简单。因此,被分成三层的应用基本上不需要修正。 (3)三层体系结构中,应用的各层可以并行开发,各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发,达到较高的性能价格比;对每一层的处理逻辑的开发和维护也会更容易些。 (4)实现分布式数据处理。把一个应用程序分布在几个机器上运行,可以提供应用程序的性能,通过冗余配置还可以保证不会因为局部故障导致整个应用程序崩溃。(5)有利于安全。允许充分利用功能层有效地隔离开表示层与数据层,将一些敏感数据功能部分封装在中间层,并授予不同访问权限,未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层,可以保证对数据的访问限制,这就为严格的安全管理奠定了坚实的基础;整个系统的管理层次也更加合理和可控制。 4.3三层体系结构 4.3.1 三层体系结构的定义所谓三层体系结构,是在客户端与数据库之间加入了一个中间层,也叫组件层。这里所 说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一 台机器上。 三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是与中间层建立连接,再经由中间层与数据库进行交换。开发人员可以将应用的商业逻辑放在中间层应用服务器上,把应用的业务逻辑与用户界面分开。在保证客户端功能的前提下,为用户提供一个简洁的界面。这意味着如果需要修改应用程序代码,只需要对中间层应用服务器进行修改,而不用修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发,简化了应用系统的开发、更新和升级工作。 4.3.3 三层体系结构的分层三层体系结构包含:表示层(USL),业务逻辑层(BLL),数据访问层(DAL) 。如图4-3所示。图4-3 三层体系结构图各层的作用:1、表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx,如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地 提供服务。2、业务逻辑层:主要是针对具体的问题的操作,也可以理解成对数据层的操作,对数据业务逻辑处理,如果说数据层是积木,那逻辑层就是对这些积木的搭建。 3、数据访问层:主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据的操作,而不是数据库,具体为业务逻辑层或表示层提供数据服务。具体的区分方法:1、表示层:主要对用户的请求接受,以及数据的返回,为客户端提供应用程序的访问。2、业务逻辑层:主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。 3、数据访问层:主要看你的数据层里面有没有包含逻辑处理,实际上他的各个函数主要完成各个对数据文件的操作。而不必管其他操作。 4.3.4 三层体系结构的优点三层体系结构的优点为:1、开发人员可以只关注整个结构中的其中某一层;2、可以很容易的用新的实现来替换原有层次的实现;3、可以降低层与层之间的依赖; 4、有利于标准化; 5、利于各层逻辑的复用。概括来说,分层式设计可以达至如下目的:分散关注、松散耦合、逻辑复用、标准定义。一个好的分层式结构,可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口,负责不同逻辑设计的开发人员就可以分散关注,齐头并进。例如UI人员只需考虑用户界面的体验与操作,领域的设计人员可以仅关注业务逻辑的设计,而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认,开发进度就可以迅速的提高。 松散耦合的好处是显而易见的。如果一个系统没有分层,那么各自的逻辑都紧紧纠缠在一起,彼此间相互依赖,谁都是不可替换的。一旦发生改变,则牵一发而动全身,对项目的影响极为严重。降低层与层间的依赖性,既可以良好地保证未来的可扩展,在复用性上也是优势明显。每个功能模块一旦定义好统一的接口,就可以被各个模块所调用,而不用为相同的功能进行重复地开发。 进行好的分层式结构设计,标准也是必不可少的。只有在一定程度的标准化基础上,这个系统才是可扩展的,可替换的。而层与层之间的通信也必然保证了接口的标准化。 4.3.5 三层体系结构的缺点降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。“三层体系结构”开发模式,不适用于对执行速度要求过于苛刻的系统,例如:在线订票,在线炒股等等它比较擅长于商业规则容易变化的系统。第五章 需求分析 5.1 登陆1. 首先实现登陆。用户输入用户名和密码及验证码实现登录系统的同能,在一定的时间内用户没有对系统做操作则自动退出系统 5.2 个人任务管理(职位高者可分配给他人任务)2. 登陆后,查看本周自己设置的任务,按星期几进行排列,可添加任务。当完成任务后,可提交任务完成。3. 领导人可查看员工任务,以及完成状态。 5.3客户信息管理4. 可添加客户及相关详细信息。5. 可根据相应条件进行客户查询。6. 可显示部分客户信息缩影,同时可根据缩影,直接查看客户详细信息,同时亦可以修改这些信息。可删除相应客户7. 查看相信信息的同时,亦可查看、添加与该客户的业务信息,同时含有“出版信息”、“教材信息”、“跟踪备忘”等8. 可导入导出客户数据,生成指定格式的EXECL文档。也可在网上采集客户数据 5.4系统管理功能9. 管理员权限部分,可添加、查看、修改所有用户的基本信息。同时进行角色分配。10. 可添加角色,根据不同的角色分配不同的权限。可进行权限编辑(修改相应的角色的权限) 5.5系统基本模块示意图5-1 系统框架图 5.6安全性需求 本系统在大型的局域网或者互联网上运行,影响面较大,整个系统的安全性显得非常重要。系统的安全性主要考虑网络安全性、系统安全性和数据安全性三个方面。(1) 网络安全性整个网络的安全首先要确保网络设备的安全,保证非授权用户不能访问任一台服务器、交换机、防火墙等网络设备。改系统要求配置了防火墙和入侵检测系统,来保护服务器,防止非法入侵。(2) 系统安全性系统采用身份认证机制对一般用户进行管理,用户只有拥有合法的用户名和口令才能进入系统,使用相应许可的操作。对拥有特殊操作的用户,不仅仅要求具有合法的用户名和口令,还应该检查IP地址是否正确,或通过其他措施,以保证其操作的合法性,保证系统的安全和完整。(3) 数据安全性为了避免系统崩溃等意外事件的发生而造成的数据丢失现象,本系统的数据库服务器存储采用RAIDS磁盘阵列。防止数据丢失,保证系统可靠运行。对数据库系统提供完全、增量等多种备份方式,如异地存储、光盘刻录等。这样可以起到对历史数据的备份,防止误操作等带来的不必要损失。 5.7性能需求(1) 时间特性本系统在大型的局域网或者互联网上运行,对全企业员工提供考试管理和信息查询服务,有可能在使用过程中会产生访问量和信息量较大的情况。为保证给用户提供方便有效的服务,整个系统采用三层架构框架设计,提高系统的响应时间。为了保证数据处理速度,提供了历史数据备份处理功能,这样可以减轻数据处理量,提高响应速度。考虑到Internet上大量用户的并发访问处理,系统采用数据缓冲池技术,对用户访问进行排队管理,保证系统的稳定和访问响应的及时,避免了大量占用系统资源以致系统性能下降甚至崩溃。(2) 适应性由于系统采用三层架构框架模式,能够将数据访问、逻辑事务处理和用户界面三者分离,这样使数据结构和业务流程的变化对系统界面的影响大大降低,使整个系统具有很强的扩展性,对今后的需求改变有了很好的适应性。该系统面向的应用群体专业不一,层次复杂,这就要求系统业务流程简明、方便、实用,表达的信息通俗、严谨、科学,界面简洁、清晰,同时设计必要的提示信息。第六章 概要设计 6.1 系统主要功能模块系统主要由系统登录、客户数据、任务计划、系统管理四大模块以及其中具体的十多个功能模块组成。如下图所示:登录系统客户数据任务计划系统管理添加客户查看客户导入导出数据网上采集客户我的任务今天任务设置任务管理任务账户管理角色管理6-1 系统功能结构图 6.1.1 功能概述 系统登录登录设置了2种权限,依据权限不同现实不同的功能界面。 .提供员工登录,进入任务计划、客户数据功能模块。 .提供系统管理员登录,进入系统管理、客户数据、任务计划功能模块。 客户数据 .添加客户,用户添加客户的详细信息。对客户的资料进行添加。 .查看客户,根据多条件查询客户的信息。在需要了解客户的信息的时候对客户的信息进行查看。 .导入、导出数据,客户的所有信息可以通过本模块导出Execl,需要按照一定的格式导入数据。 .网上采集客户,主要是实现客户自己填写个人信息,或对客户自己的信息补充。 任务计划 .我的任务,对用户的全部任务查看。 .今天任务,显示今天的任务信息。 .设置任务,对每天的任务设置。管理员可以分配任务。 .管理任务,查看任务执行状态,及可以对任务进行修改,查看任务执行时间、执行人。 系统管理系统管理员登录后能够进行的操作 .账户管理,添加用户,修改用户。刷新用户信息。 .角色管理,添加角色,为角色分配权限。 6.1.2 系统重点,难点。重点: 整个系统的整体框架的设计。及多层体系结构中的耦合度。难点:系统的业务方面,由于权限比较多。所以系统需要对在权限这块多花时间。NHibernate融入到系统。还有就是jQuery在系统中的使用。 6.1.3 用例图6-2 用例图第七章 数据库设计 7.1 数据字典表名:Customs客户信息表序号列名数据类型长度小数位标识主键允许空默认值说明1CustomsIDnvarchar500是否客户ID2CustomsNamenvarchar500是客户姓名3Sexnvarchar100是性别4Birthdaynvarchar500是生日5Addressnvarchar2000是住址6Zipnvarchar500是邮编7OfficeTelnvarchar500是工作电话8ZoneDescriptionnvarchar500是区号9Mobnvarchar500是移动电话10HomeTelnvarchar500是家庭电话11Faxnvarchar500是传真12Emailnvarchar500是邮件13QQnvarchar500是QQ号码14POPOnvarchar500是POPO15MSNnvarchar500是MSN16Schoolnvarchar1000是毕业学校17Majornvarchar1000是学历18Companynvarchar1000是工作单位19CompanyTypenvarchar500是工作类型20CompanyCitynvarchar500是单位所属省份21Collegenvarchar1000是院系部门22TecherGroupnvarchar1000是教研室23TecherPositionnvarchar500是职务24Offi

温馨提示

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

最新文档

评论

0/150

提交评论