基于Docker的云计算快速开发测试架构(完整资料)

基于Docker的云计算快速开发测试架构(完整资料）(可以直接使用，可编辑优秀版资料，欢迎下载）

基于Docker的云计算快速开发测试架构(完整资料）(可以直接使用，可编辑优秀版资料，欢迎下载）基于Ｄockｅｒ的云计算快速开发测试架构中国邮政集团公司山东省信息技术局马岩概述随着山东邮政业务转型的深入和业务种类的多样化发展,迫切需要邮政IT部门的支撑和引领作用，特别是在当前业务发展迅速，各业务功能开发和上线频繁的情况下,对我们的系统开发能力提出了更高的要求，而现有的开发测试环境存在资源利用效率低，测试版本管理复杂,迁移成本高等诸多缺点.以Docｋｅｒ为代表的容器云计算技术自去年起逐步成长起来，容器技术以它轻量，快速，隔离的优势，迅速在IT学术界和企业界引起了广泛的关注。本文在概述Ｄocｋeｒ容器核心技术理念基础上,着重介绍了我们利用Docker容器云计算技术优化系统开发过程的思路，并搭建了一个以dockｅr技术为基础的开发测试框架。该框架有效整合了开发和测试环境，显著提高了我们开发测试的速度和质量，使我们能更好的服务于业务的发展。Dｏcｋer容器云计算技术2。1Ｄockeｒ核心技术Docker是以Lｉnux的cgroup、nａmespace等容器技术为基础的开源容器引擎,目前已经获得包括微软，Google，红旗等主流ＩT厂商的支持.Docｋｅr利用轻量级的虚拟化技术，有效的封装了操作系统底层的隔离，进程独立等功能,实现了各种依赖环境和应用的打包，方便了项目的开发测试和部署过程。Docｋer与传统虚拟机技术的对比：传统的虚拟化技术例如vmwaｒe公司的vｓpheｒe目标是建立一个从硬件到软件模拟化的虚拟机，具有整套的操作系统环境，而Dｏcker技术则是基于操作系统的底层容器API，他没有模拟完整的操作系统环境,从进程上看，dｏcｋer虚拟机里只有应用的进程而没有其他的操作系统进程，它将项目的源码,依赖和环境配置打包成一个隔离独立的运行环境，所以它具有快速轻量的特点。2.２Dockeｒ解决的主要问题２.2．１减轻虚拟化的成本传统的虚拟机技术要安装操作系统后才能使用，而操作系统本身会占用大量的系统资源，是一种极大的浪费。而Ｄocker容器不需要操作系统安装也能运行,在提供了进程隔离的同时,为应用的运行提供了有效的运行环境。2。2.2应用的快速运行和部署Doｃkｅr独有的镜像技术，使各种环境依赖和应用打包后形成镜像存储在Dｏcker仓库中,当需要部署运行的时候，只要从仓库获取运行镜像即可得到相应的功能，ｄocker将复杂的部署过程，简化为复制加运行，不需要中间多余的工作.2.2．3资源的有效度量Docker利用操作系统的容器APＩ可以对cpu，网络，内存等各种资源进行有效的定制和度量，减少了单个应用死循环对其他应用的影响.2。2.４复杂环境依赖的有效隔离应用的运行环境需要多种第三方插件和运行中间件的支持，这给应用的开发测试带来了很大的复杂性,往往新环境的搭建要耗费大量的时间和精力。Ｄockeｒ通过将多种依赖库和中间件打包成镜像的方法，有效减轻了环境搭建和移植的复杂性,同时Ｄocker支持镜像的叠加，容器的网络等功能，从而进一步简化了环境构建的工作。2.3Doｃkeｒ的主要部件Doｃkeｒ主要部件包括Dｏcｋｅr客户端，docｋer后台进程，ｄoｃｋeｒ镜像仓库和docker容器进程四个部分。2。3．1Ｄｏckeｒ客户端用户通过Docｋer客户端与docker后台守护进程进行通讯,通过Docker客户端命令行工具,发起对Ｄockeｒ各种功能的操作指令.Dｏckｅr通讯支持tcp，unixsｏckeｔ等多种通讯方式。2．3.2Docker后台守护进程Docker后台守护进程包含两个模块，Ｄocｋｅr服务和Docｋer引擎。Docker服务接受来自Ｄoｃker客户端发送的命令,并交由Dｏcｋer引擎中相应的处理程序进行处理。Doｃkｅr引擎是实际完成工作的核心进程。２。3.3Dockeｒ仓库Dockeｒ仓库用于存放Dｏcｋer镜像。镜像类似虚拟机的快照概念，是Ｄoｃker容器运行的代码基础。Docｋer仓库可以使用公有仓库DockｅrHub，也可以搭建企业内部的私有仓库。2。3.4ＤoｃkerFｉle构建文件DoｃkerFile描述了一个完整的镜像的构建过程，包括依赖软件和中间件的安装，目录,环境变量,暴露端口，端口映射等。基于Docker容器的云计算快速开发测试框架3。1现有开发测试环境及存在的问题下图是一个开发测试和部署的过程,传统的开发测试过程存在如下几个问题:1、资源利用效率低2、单物理机多应用无法有效隔离（进程空间，cpu资源,磁盘)3、运维部署不便4、测试、版本管理复杂5、迁移成本高6、传统虚拟机,空间占用大,启动慢，管理复杂一个IT系统应该包含如下几个层次：应用程序运行时平台(bin/ｆramｅｗorｋ/lib）操作系统硬件（基础设施)开发人员的主要工作是应用程序的编码、构建、测试和发布,涉及应用程序和运行时平台这两层.而运维人员的工作则涉及从硬件、操作系统到运行时平台的安装、配置、运行监控、升级和优化等工作。ｄoｃｋer提供了一种运行时环境,隔离了上层应用于下层操作系统和硬件的关联，使得术业有专攻。3。2Dockｅｒ容器的云计算快速开发测试框架框架流程图如下：如上图所示，通过创建镜像仓库群，开发用户从仓库获取标准镜像，进行开发测试,完成后将结果镜像保存在Ｄoｃker镜像仓库中,测试机从仓库中获取开发完成的镜像,并进行验证测试,测试通过后，生产环境可以获取最新的镜像进行部署，同时对原有镜像进行备份处理。3．2．１框架部署结构图框架部署图如下所示:我们通过vmwaｒe公司的ｖsｐherｅ软件建立虚拟化集群，在虚拟化集群服务中建立云端Docｋｅｒ仓库服务器,测试机和生产服务器，开发人员通过网络连接Docker镜像仓库，下载需要开发的环境镜像文件，同时可以根据生产备份和测试备份，直接获取生产版本或者测试版本，开发后在生产环境进行部署.３.3关键技术及过程1、容器创建容器的创建过程类似于快照中创建虚拟机,可以把容器看做是一个简易版的Linux环境（包括rｏot用户权限、进程空间、用户空间和网络空间等）和运行在其中的应用程序.容器是从镜像创建的运行实例。它可以被启动、开始、停止、删除。每个容器都是相互隔离的、保证安全的平台.如上图所示，我们从#0号镜像创建了tomcａt容器2、端口映射端口映射功能提供了一种容器之间通讯的一种手段，如下图所示:容器myaｐp1将内部的80端口映射成808０端口对外提供服务3、数据卷共享数据卷是一个可供一个或多个容器使用的特殊目录，完成进程和数据的分离,实际保存在容器之外，从而允许你在不影响数据的情况下销毁、重建、修改、丢弃容器，可用于数据持久化。数据卷的使用，类似于Linux下对目录或文件进行moｕnｔ.数据卷的共享，可以在多个容器之间共享数据卷上图中深绿色表示数据卷以及数据卷在各容器之间的共享４、链接容器容器的连接（liｎkｉng）系统是除了端口映射外，另一种跟容器中应用交互的方式.在源和接收容器之间创建一个隧道，接收容器可以看到源容器指定的信息，Docker在两个互联的容器之间创建了一个安全隧道，而且不用映射它们的端口到宿主主机上。从而避免了暴露关键系统(如数据库）端口到外部网络上。如上图所示，ｗｅb容器与ｍyapp_db容器之间通过链接方式将数据库的端口开放给web应用。５、仓库创建及注册仓库是集中存放镜像文件的场所,仓库注册服务器上往往存放着多个仓库,每个仓库中又包含了多个镜像，每个镜像有不同的标签，仓库分为公开仓库(Ｐubｌic)和私有仓库（Privａｔe）两种形式,可以push镜像到仓库或者从仓库pｕll下镜像。总结创新点与成效比较传统的开发测试流程和以dｏcker为基础的开发测试框架,提出了三处创新:简化了环境搭建的步骤以往开发环境的搭建，需要自己安装操作系统，安装各种中间件软件和依赖库，采用ｄoｃkｅr容器后,我们需要的仅仅是复制运行,中间环节全部去除,并且保证了各个开发人员环境的一致性。提高了资源利用效率为了减少各个应用之间互相影响，业务测试都需要一台独立的物理主机或者虚拟机进行测试，,采用docker技术后,各个应用可以共用一台主机，由于进程,内存,ｃｐu,网络等资源的隔离，应用之间的影响降为最低。降低了迁移成本旧开发模式下，完成的代码要上线到生产环境，需要在生产环境安装需要的依赖软件和库文件，采用docker技术后，我们只需要将开发完成的镜像文件放到生产环境中运行即可，因为镜像本身就带有自己的依赖文件和环境参数,不需要运维人员进行修改和调整。基于Docker云计算的开发测试环境的应用成效：采用该框架后,我们的开发测试工作中的环境搭建任务大为减轻,开发质量和交付速度显著提高，有效支撑了业务的发展通过浏览博客园的文章发现，很多朋友对分层架构特别感兴趣，刚好我刚做完的毕业设计就是专门研究．NＥT平台上分层架构的（题目叫“基于.NET平台的分层架构与设计模式应用研究”）.通过做这篇论文,我对分层架构有了一定的了解，所以，就萌发了想写一个文章系列，详述一下分层架构。然而，论文的理论性太强，不适合在网上发布,尤其不适合初学者理解，所以，我想在这个文章系列中,少讲理论，而是通过做一个完整的案例来讨论分层架构的基本方法，这样会直观很多。希望在这个文章系列的写作过程中，能和朋友们一起学习,一起进步。

为了让朋友们把主要精力放在理解分层架构而不是案例本身，我准备选择一个相对简单的留言本系统作为Deｍo,这个系统的名字就叫做NGuestBｏok。

ﻫ

初步计划将这个文章系列分为以下几篇：

１．综述ﻫ

２.系统需求分析及数据库设计ﻫ

3．架构概要设计

４.实体类的实现ﻫ

５。接口的设计与实现

6。依赖注入及IoＣ的设计与实现

７。数据访问层的第一种实现——Ａccess+动态生成ＳQL语言ﻫ

8.数据访问层的第二种实现——SQLSｅｒveｒ+存储过程ﻫ

9.数据访问层的第三种实现——基于NBeaｒ框架的ORM实现ﻫ

10．业务逻辑层的实现

１1。表示层的实现ﻫ

1２。使用ＡSP.NETＡJAX框架对表示层进行改进

13.总结

当然,以上只是初步计划，在写文章的过程中可能会根据具体情况适当调整,但是内容大体就是这些。

这个文章系列不会对所用到的技术进行详细讲解，具体请参考相关文献，阅读文章前最好能对以下技术有一个了解：ﻫ

1.Ｃ＃语言ﻫ

2。ASＰ．NETﻫ

３.设计模式

４.关系数据库基础知识ﻫ

５．软件架构基本原则与软件工程基础知识ﻫ

６。基于NBear框架的ORＭ技术

7。ＪａvａＳcript，Ajax

８。AＳP.NETAJAX框架（特别是客户端编程）ﻫ

９．HTML，ＣSS,标准化布局ﻫﻫ

另外,本文章系列是基于.NEＴfraｍewoｒｋ2.0框架平台进行讨论，３。5平台的新特性(如ＬINQ、ASP.NＥTMＶＣ等)不会讨论,IＤＥ使用VisualStudｉｏ２005,数据库会用到SQLSｅｒver20０5Eｘprｅss和Accｅss2003。在实际的项目中,需求分析和数据库的设计是很重要的一个环节，这个环节会直接影响项目的开发过程和质量。实际中，这个环节不但需要系统分析师、软件工程师等计算机方面的专家,还需要相关领域的领域专家参与才能完成。ﻫﻫ

但是，在这个文章系列中,所要使用的Deｍｏ仅仅是一个例子，而且其业务极为简单,因此,这里并不是真正的需求分析和数据库设计，而是将Deｍo的需求和数据库罗列至此，使朋友们对Demo有一个大体的了解，方便后续文章中开发过程的理解。

需求分析:

这个项目是一个留言本,其业务极为简单，现将其描述如下。

１．任何访问者可以进行留言,留言完成后，不会立即显示正文,而是要经过管理员验证后才可显示。

2。任何访问者可以对留言发表评论,未通过验证的留言不可以评论。ﻫ

3.管理员可以对留言进行回复（这个回复不同于评论，是直接显示在正文下面,而且是一个留言只能有一个回复），并可对留言与评论实行删除，以及对留言进行通过验证操作。ﻫ

４.管理员分为超级管理员和普通管理员。超级管理员只有一个，负责对普通管理员实行添加、删除操作.普通管理员可偶多个，负责对留言的管理，并可以修改自己的登录密码.

ﻫ

这个项目的用例图如下:ﻫ

数据库设计：ﻫ

设计数据表之前，首先进行实体和关系的识别与确定。ﻫ

通过需求分析，可以观察得出,本项目的实体有:管理员(不包括超级管理员），留言,评论。本项目的关系有：留言与评论间的一对多关系.ﻫﻫ

进一步，数据库各表的设计如下:

ﻫ

管理员表（ＴAdmin）ﻫ

IＤ

int

管理员ID

NｏtNｕll

主键，自增

Namｅ

ｖarｃhａr（２0)

登录名

NotNull

Pａｓswoｒd

vａrｃhar(50)

登录密码

NotNull

使用ＭD5加密ﻫﻫ

留言表（TＭｅsｓage）

ID

int

留言ID

NotNull

主键,自增

GuestName

varcｈａr（20）

留言者用户名

NotNｕｌｌ

GuｅstEmａil

varchar(100)

留言者Ｅ-ｍail

Nｕll

Cｏntent

text

留言内容

NotNｕlｌﻫ

Tｉｍｅ

ｄatｅtiｍe

发表留言时间

NotNｕll

ﻫ

Repｌy

text

回复

Null

ＩsPass

vaｒｃhar（1０）

是否通过验证

ＮotNull

ﻫ

评论表(TComｍｅnｔ）

Ｃontｅnｔ

tｅxt

评论内容

NotＮｕlｌﻫ

Time

ｄatetimｅ

发表评论时间

NotNｕll

ＭessageID

int

所属留言的ID

外键基于。NET平台的分层架构实战（三）—架构概要设计

本文主要是对将要实现的架构进行一个总体的描述,使朋友们对这个架构有个宏观上的认识。这篇文章理论性的东西会偏多一点，从下篇开始,将进行实际项目的开发.这篇文章的许多内容摘自我的毕业论文.架构基本原则：这里，将描述一些在这个架构设计中的基本原则，其中很多都是经典的设计原则,不过针对分层架构的特点,用我自己的语言进行了描述。其中也有我自己提出的原则。逐层调用原则及单向调用原则现在约定将N层架构的各层依次编号为1、2、…、Ｋ、…、N－1、N，其中层的编号越大，则越处在上层.那么，我们设计的架构应该满足以下两个原则：1.第K(12.如果P层依赖Q层，则P的编号一定大于Q。其中第一个原则,保证了依赖的逐层性,及整个架构的依赖是逐层向下的,而不能跨层依赖。第二个原则，则保证了依赖的单向性,及只能上层依赖底层,而不能底层反过来依赖上层。针对接口编程，而不是针对实现编程

这里所指的接口,不是特指编程语言中的具体语言元素(如Ｃ#中由Inｔeｒｆace定义的语言接口），而是指一种抽象的，在语义层面上起着接合作用语义体。它的具体实现,可能是接口，可能是抽象类，甚至可能是具体类。我认为，从不同的视角,接口可以有以下两种定义：１．接口是一组规则的集合，它规定了实现本接口的类或接口必须拥有的一组规则。体现了自然界“如果你是……则必须能……”的理念。2。接口是在一定粒度视图上同类事物的抽象表示。注意这里我强调了在一定粒度视图上，因为“同类事物”这个概念是相对的,它因为粒度视图不同而不同。具体到N层架构中，针对接口编程的意义在部分上是这样的：ﻫ现仍约定将Ｎ层架构的各层依次编号为1、2、…、K、…、N-1、N，其中层的编号越大,则越处在上层，那么第K层不应该依赖具体一个K-１层，而应该依赖一个K－１层的接口,即在第K层中不应该有K—1层中的某个具体类.依赖倒置原则在软件设计原则中，有一种重要的思想叫做依赖倒置。它的核心思想是：不能让高层组件依赖底层组件,而且,不管高层组件和底层组件,两者都应依赖于抽象。那么,这个原则和我们上面的原则是否矛盾呢?其实并不矛盾。因为这个原则定义中的“依赖”是指“具体依赖"，而上面定义中的依赖全部指“抽象依赖”。我对这两种依赖的定义如下：具体依赖——如果P层中有一个或一个以上的地方实例化了Q层中某个具体类,则说P层具体依赖于Ｑ层。抽象依赖—-如果Ｐ层没有实例化Q层中的具体类，而是在一个或一个以上的地方实例化了Q层中某个接口，则说P层抽象依赖于Ｑ层，也叫接口依赖于Q层。从这两个定义可以看到,所谓的依赖倒置原则,正是上面提到针对接口编程，而不是针对实现编程,两者在本质上是统一的.综上所述,可以看出，本课题设计的分层架构,应该是这样一种架构:ﻫ１。Ｎ层架构的各层依次编号为１、2、…、K、…、N—1、N，其中层的编号越大,则越处在上层。2.架构中仅存在一种依赖，即第K层接口依赖第K—1层，其中1封装变化原则封装变化的原则定义为：找出应用中可能需要变化之处，把它们独立出来,不要和那些不需要变化的代码混杂在一起。开放－关闭原则开发-关闭原则定义为：对扩展开放,对修改关闭.具体到Ｎ层架构中，可以描述为:当某一层有了一个新的具体实现时,它应该可以在不修改其他层的情况下，与此新实现无缝连接，顺利交互。单一归属原则在这个架构中，任何一个操作类都应该有单一的职责，属于单独的一层,而不能同时担负两种职责或属于多个层次（实体类及辅助类可以被多个层使用，但它们不属于任何一个层，而是独立存在)。层次划分：目前，典型的分层架构是三层架构,即自底向上依次是数据访问层、业务逻辑层和表示层.这种经典架构经历了时间的考验和实践的多次检验,被认为是合理、有效的分层设计，所以，在本文中，将沿袭这种经典架构，使用数据访问层、业务逻辑层和表示层的三层架构体系.职责划分：

目前，在典型的三层架构中,对层次各自的职责划分并没有一个统一的规范，综合现有的成功实践和.NET平台的特殊性,在本文中将三层架构的职责划分如下：

数据访问层--负责与数据源的交互，即数据的插入、删除、修改以及从数据库中读出数据等操作。对数据的正确性和有效性不负责,对数据的用途不了解，不负担任何业务逻辑。业务逻辑层--负责系统领域业务的处理，负责逻辑性数据的生成、处理及转换。对流入的逻辑性数据的正确性及有效性负责，对流出的逻辑性数据及用户性数据不负责，对数据的呈现样式不负责。表示层-—负责接收用户的输入、将输出呈现给用户以及访问安全性验证。对流入的数据的正确性和有效性负责,对呈现样式负责，对流出的数据正确性不负责,但负责在数据不正确时给出相应的异常信息。模块划分及交互设计：综合以上分析,可在宏观上将整个系统分为一下几个模块：实体类模块-—一组实体类的集合，负责整个系统中数据的封装及传递。数据访问层接口族——一组接口的集合，表示数据访问层的接口。业务逻辑层接口族--一组接口的集合，表示业务逻辑层的接口。数据访问层模块——一组类的集合,完成数据访问层的具体功能，实现数据访问层接口族。业务逻辑层模块——一组类的集合，完成业务逻辑层的具体功能,实现业务逻辑层接口族。表示层模块——程序及可视元素的集合，负责完成表示层的具体功能。IoC容器模块——负责依赖注入的实现。辅助类模块——完成全局辅助性功能。各模块见交互关系如下：

图1这篇中理论比较多，但是它是整个架构的基础，可以帮助朋友们对将要实现的项目架构及要遵循的原则有一个整体的了解.当然,在后续文章中，将主要讨论Ｄemｏ项目的实际开发过程,那时,这些思想和理论性的东西将得到体现。实体类是现实实体在计算机中的表示。它贯穿于整个架构，负担着在各层次及模块间传递数据的职责。一般来说,实体类可以分为“贫血实体类”和“充血实体类”，前者仅仅保存实体的属性，而后者还包含一些实体间的关系与逻辑.我们在这个Deｍｏ中用的实体类将是“贫血实体类"。ﻫﻫ

大多情况下，实体类和数据库中的表（这里指实体表，不包括表示多对多对应的关系表）是一一对应的，但这并不是一个限制,在复杂的数据库设计中,有可能出现一个实体类对应多个表，或者交叉对应的情况。在本文的Demo中，实体类和表是一一对应的，并且实体类中的属性和表中的字段也是对应的。

ﻫ

在看实体类的代码前,先看一下系统的工程结构。

如上图所示，在初始阶段，整个系统包括6个工程，它们的职责是这样的:ﻫ

Web—-表示层

Ｅntitｙ——存放实体类

Factory——存放和依赖注入及ＩoＣ相关的类

IＢＬL——存放业务逻辑层接口族ﻫ

ＩDAＬ-—存放数据访问层接口族ﻫ

Uｔility--存放各种工具类及辅助类

ﻫ

这只是一个初期架构，主要是将整个系统搭一个框架,在后续开发中,将会有其他工程被陆陆续续添加进来.

我们的实体类将放在Eｎtｉty工程下，这里包括三个文件:ＡｄminＩnfo．cs,MessａgeInfo。cs，ＣommeｎtIｎfo。cｓ,分别是管理员实体类、留言实体类和评论实体类。具体代码如下:

ＡdmｉnIｎｆo。ｃs：

1usinｇ

Sysｔem；

2

３namespaｃｅ

NGuestBook.Entｉty

4{ﻫ

５

///

<ｓummａry>

６

///

实体类—管理员ﻫ

7

///

</summａry>

8

［Serｉalizａbｌe］ﻫ

9

ｐubｌiｃ

cｌaｓs

AｄminＩnｆoﻫ10

｛

１１

privａｔｅ

ｉnt

id；

12

pｒivate

string

nａme；

13

ｐrivate

sｔrｉng

passwｏｒd;

1415

public

int

IDﻫ16

{

17

get

｛

return

ｔhis．id；

}

１８

set

{

this。ｉd

=

vａlue；

｝ﻫ19

｝ﻫ202１

pｕbliｃ

string

Namｅ

２2

｛

２3

geｔ

｛

ｒetｕｒn

ｔhiｓ．name；

｝

24

seｔ

{

tｈｉs．naｍe

＝

valｕｅ；

}

25

｝ﻫ2６27

ｐｕbｌic

string

Passwordﻫ28

｛

２９

gｅt

｛

ｒeｔurn

tｈｉs．paｓsword;

｝ﻫ30

set

{

tｈis.paｓsworｄ

＝

ｖaluｅ;

}

31

｝ﻫ3２

｝

33｝

34

MesｓagｅＩnｆo．ｃs：

1ｕsing

Ｓystem；

２

3namesｐace

NGuestBook。Entity

４{

5

//／

〈sｕmmａｒｙ＞

6

//／

实体类-留言ﻫ

７

///

〈/ｓummary〉

8

[Seriaｌｉzable]

9

publiｃ

claｓｓ

ＭｅssagｅInfoﻫ１0

｛

１１

pｒivaｔe

ｉnt

ｉｄ；

12

ｐｒivate

sｔｒing

ｇueｓtNａme；

13

privａte

striｎｇ

gｕesｔEmaｉl;

14

ｐrｉvate

strinｇ

conｔeｎｔ;

1５

privａte

DaｔeTime

ｔｉｍe；ﻫ１6

pｒiｖaｔe

strｉng

replｙ；ﻫ17

private

ｓtｒiｎｇ

isＰaｓｓ；ﻫ1819

publiｃ

inｔ

IDﻫ20

{

21

ｇet

｛

ｒeturn

thｉs.iｄ；

｝ﻫ22

seｔ

{

thｉｓ.id

＝

valuｅ；

}

23

}

2４25

ｐuｂｌic

string

GuesｔＮaｍeﻫ２6

{

2７

gｅt

｛

returｎ

this.ｇuesｔNａme;

}ﻫ28

sｅt

｛

tｈis.ｇuｅsｔName

=

vaｌue；

｝ﻫ29

｝ﻫ3031

publiｃ

stｒing

GuestEmaｉlﻫ32

{ﻫ33

geｔ

{

ｒｅturｎ

tｈis.guestEmａｉl；

}ﻫ3４

set

｛

this.guｅstEmail

＝

ｖalue；

}

3５

}ﻫ3637

pｕblic

string

Cｏntentﻫ３8

{ﻫ39

ｇet

{

ｒｅturn

ｔhis。conｔent；

}ﻫ40

sｅt

｛

thiｓ.content

=

value；

｝

4１

｝

4243

pｕｂlｉｃ

DateTiｍe

Timｅ

44

｛ﻫ45

get

｛

retuｒｎ

this。tｉme；

}ﻫ46

ｓet

{

thiｓ．time

=

vaｌｕe；

｝

47

}ﻫ４849

puｂliｃ

stｒｉng

Replyﻫ50

｛

51

ｇet

｛

ｒeturn

thｉs。reply;

｝

52

set

{

ｔhｉs.reｐly

=

value；

｝

５３

}ﻫ5４55

pｕblic

striｎg

ＩsPａssﻫ5６

｛

57

gｅt

{

ｒeturn

tｈis.isＰasｓ；

｝ﻫ58

ｓｅt

{

tｈis.ｉｓPａsｓ

=

valｕe;

}

59

｝ﻫ60

}

６1}ﻫ62

ComｍeｎtIｎfｏ.cs:

１using

System；ﻫ

2

3ｎaｍｅｓpace

ＮGｕeｓtBｏok。Eｎｔｉｔy

4｛ﻫ

５

///

〈suｍｍａｒy＞

6

///

实体类－评论ﻫ

7

///

〈/ｓummary〉

8

[Serializable］

9

public

clａss

CoｍｍeｎtInfoﻫ1０

｛ﻫ11

ｐrivaｔe

ｉｎｔ

id；ﻫ1２

pｒivate

striｎg

coｎｔent;

13

ｐrivａte

ＤateTime

time;ﻫ14

ｐrｉvaｔe

ｉｎt

message;ﻫ1516

ｐｕblic

int

ID

17

｛ﻫ18

geｔ

｛

return

this．id；

}ﻫ１9

seｔ

｛

ｔｈiｓ.id

＝

value；

｝

２0

}

２122

public

ｓｔｒinｇ

Ｃonteｎtﻫ2３

{ﻫ2４

geｔ

｛

ｒeturｎ

thｉs．ｃｏnteｎt；

｝

25

set

{

this.ｃonteｎｔ

＝

ｖalue；

}

2６

｝

２7２８

public

DａteTime

Ｔｉmeﻫ2９

｛

30

get

｛

rｅtuｒｎ

this．ｔｉme；

｝ﻫ31

set

{

thiｓ.tiｍｅ

=

vaｌｕe；

}ﻫ３2

}

333４

puｂｌic

iｎt

Mesｓaｇe

35

{ﻫ３6

get

｛

rｅturn

this．meｓsage；

｝

3７

set

{

thｉs。mｅssaｇe

=

vaｌue；

｝

38

｝ﻫ39

｝

４０｝ﻫ４1

大家可以看出,实体类的代码很简单,仅仅是负责实体的表示和数据的传递,不包含任何逻辑性内容。下篇将介绍接口的设计。接下来，将进行接口的设计。这里包括数据访问层接口和业务逻辑层接口.在分层架构中，接口扮演着非常重要的角色，它不但直接决定了各层中的各个操作类需要实现何种操作,而且它明确了各个层次的职责。接口也是系统实现依赖注入机制不可缺少的部分。

ﻫ

本项目的接口设计将按如下顺序进行：ﻫ

1．首先由前文的需求分析,列出主要的ＵI部分.

2.分析各个ＵI需要什么业务逻辑支持，从而确定业务逻辑层接口。ﻫ

３。分析业务逻辑层接口需要何种数据访问操作，从而确定数据访问层接口。ﻫ

另外，为保证完全的面向对象特性，接口之间的数据传递主要靠实体类或实体类集合,禁止使用DataTaｂle等对象传递数据。

由需求分析，列出主要UＩ

需求分析部分，请参看基于。ＮEＴ平台的分层架构实战（二)——需求分析与数据库设计。有需求分析，可以列出系统中主要应包括以下UI:ﻫ

ＵI01——主页面，列出全部的留言及相应评论，支持分页显示.留言按发表时间逆序显示，评论紧跟在相应留言下.管理员可以通过相应链接对留言执行通过验证、删除、回复以及对评论进行删除操作。游客可通过相应连接进入发表留言评论页面。ﻫ

UI0２—-发表留言页面，供游客发表新留言.

UI03--发表评论页面，供游客发表评论。

UI0４-—回复留言页面，供管理员回复留言.

ＵI05—-管理员登录页面。

UＩ０6-—管理员修改个人密码的页面。

UI07——超级管理员登录后的页面，主要提供管理员列表。可以通过相应链接将指定管理员删除。ﻫ

UI０8—-添加新管理员的页面。

UI0９-—操作成功完成后的跳转提示页面。

UI10——系统出现异常时显示友好出错信息的页面。ﻫ

由UI识别业务逻辑操作

ＵI01：按分页取得留言，按指定留言取得全部评论,将指定留言通过验证，将指定留言删除，将指定评论删除

UI02：添加新留言

ＵI0３:添加新评论

ＵI04:回复留言

ＵI05：管理员登录ﻫ

UＩ06：修改管理员密码ﻫ

UＩ０７：取得全部管理员信息,删除管理员ﻫ

UＩ０8:添加新管理员ﻫ

经过整理,可得以下接口操作：

IAdｍｉnＢLL:Aｄｄ（添加管理员)，Reｍｏve（删除管理员），CｈangePａsｓworｄ（修改管理员密码），Loｇｉn（管理员登录）,ＧetAll（取得全部管理员）

ＩMesｓageBLL:Ａdd(添加留言)，Ｒｅmovｅ(删除留言），Revｅrt（回复留言），Ｐass（将留言通过验证),GeｔByPaｇe(按分页取得留言)ﻫ

ICommentＢＬＬ：Add(添加评论)，Rｅmove（删除评论）,GetＢｙＭessａge（按留言取得全部评论）

这三个接口文件都放在IＢLL工程下,具体代码如下：

ﻫIＡdminBＬL.cs：

1usiｎg

Ｓystｅm；ﻫ

2using

Systｅm.Cｏlleｃtｉons.Ｇeneｒｉｃ;ﻫ

３usｉnｇ

Sysｔem.Teｘt；

4ｕsing

ＮGｕeｓtBook。Entity；ﻫ

5

６naｍeｓpaｃｅ

ＮGｕestＢooｋ．IBLLﻫ

７{

8

///

〈sｕmmary>

9

///

业务逻辑层接口—管理员ﻫ10

///

〈/summａｒy〉１1

public

ｉnterfａｃｅ

IAdmｉｎBLLﻫ１2

{

13

／//

＜summary〉14

／//

添加管理员

15

///

</summａry〉1６

///

〈ｐaraｍ

nａｍe=”admｉｎ＂>新管理员实体类＜/paｒａm〉17

//／

＜rｅtｕrｎs>是否成功</reｔurｎｓ>１8

ｂool

Adｄ(ＡdｍｉnIｎfｏ

aｄmin);ﻫ1920

///

〈ｓuｍｍarｙ>２1

/／/

删除管理员ﻫ22

//／

＜/summary>２3

///

<parａｍ

namｅ=＂iｄ”〉欲删除的管理员的ID</paｒam>24

///

<reｔuｒnｓ>是否成功〈/ｒeturnｓ>2５

booｌ

Remｏve（int

ｉd）；

2627

///

〈ｓummａry＞２８

///

修改管理员密码

２9

///

＜/summary>３０

///

<pａｒａm

naｍｅ=”id”>欲修改密码的管理员的IＤ＜/paraｍ>３1

///

〈parａm

nａｍe＝"ｐassword＂＞新密码〈/param〉32

///

<ｒetuｒnｓ〉是否成功<／rｅturｎｓ>３3

ｂooｌ

ChangeＰaｓsｗorｄ(int

id，strｉng

paｓsｗord）;

3435

／//

<ｓumｍａrｙ〉3６

/／/

管理员登录

３7

///

</sumｍary>3８

/／/

〈ｐａｒam

namｅ=”name＂〉管理员登录名〈/paｒaｍ〉３９

／//

<parａm

name=”ｐassword＂＞管理员密码〈／parａm>40

///

〈returns〉如果登录成功,则返回相应管理员的实体类，否则返回null</ｒeturns＞４１

AdminInｆo

Lｏｇin(ｓtring

ｎａme,sｔｒｉnｇ

paｓswｏｒd）;ﻫ4２43

//／

＜ｓummary〉4４

///

取得全部管理员信息ﻫ45

///

＜/summａry＞4６

//／

＜returnｓ〉管理员实体类集合<／reｔuｒns〉４7

ＩList〈AdｍinIｎfｏ＞

ＧｅtAll()；

４8

}ﻫ49｝ﻫIMｅssageBLL.cs:

1uｓiｎg

Sｙstｅm；

２using

Syｓｔem.Ｃolleｃｔioｎs。Ｇenｅrｉc；

３usｉng

System。Ｔext;

4using

NGｕeｓｔＢｏｏk.Eｎtity；

５

６naｍespacｅ

NGuesｔBｏoｋ.IBLLﻫ

7{

8

/／/

〈ｓｕmmaｒy〉

９

///

业务逻辑层接口—留言ﻫ10

///

</ｓummary>11

ｐｕblic

interｆaｃe

IMessaｇeBLＬﻫ12

｛ﻫ13

／/／

＜summary>14

//／

添加留言ﻫ1５

///

〈/summａry>16

／/／

〈paｒａｍ

naｍｅ=”mｅｓsａｇｅ＂>新留言实体类〈／paraｍ>17

//／

<reｔuｒnｓ＞是否成功〈／retｕrns＞１8

bｏol

Ａdｄ（MessaｇeInｆo

mesｓage）;ﻫ1920

//／

〈ｓummary〉21

///

删除留言ﻫ22

///

＜／ｓummary＞23

///

<ｐａram

ｎame＝"id＂〉欲删除的留言的IＤ＜/param>24

///

<retｕrnｓ>是否成功＜/returｎs＞2５

boｏl

Rｅmove(ｉｎt

id)；

2６27

／//

〈summaｒy＞28

//／

回复留言ﻫ２9

//／

＜/sｕｍmａｒｙ>3０

///

〈param

name="id”〉要回复的留言的ID＜/parａｍ＞31

///

＜ｐaram

naｍe=”reｐly"＞回复信息</ｐaram〉32

//／

<retuｒns>是否成功〈／ｒeturns>３3

bool

Ｒｅvert(inｔ

id，

string

reply）;ﻫ3４35

/／／

<summａｒy〉３6

///

将留言通过验证

37

／／／

〈/ｓｕmｍａrｙ＞38

/／／

<ｐarａm

nａme=”id">通过验证的留言的IＤ</pａrａｍ>39

//／

<rｅturns〉是否成功＜／rｅｔurnｓ〉4０

ｂool

Paｓｓ（inｔ

ｉｄ)；ﻫ4142

／//

＜suｍmary〉43

///

按分页取得留言信息ﻫ44

／//

〈/ｓummarｙ〉45

///

〈parａm

ｎamｅ=”paｇeＳｉze"〉每页显示几条留言〈/paｒam〉46

／／/

＜param

nａｍｅ="paｇeNumber"〉当前页码<／ｐaｒam>４7

／//

<rｅturns＞留言实体类集合＜/reｔuｒns〉4８

IＬist〈ＭｅssageInfo＞

GeｔByPaｇe(int

pageSiｚe，ｉnｔ

pageNumbeｒ）;ﻫ4９

｝ﻫ50｝

ICoｍmeｎtBLL。ｃs

1usｉｎg

Sｙstem;

2using

Systeｍ。Coｌlectioｎs。Genｅric；

3using

System．Texｔ;

4uｓing

ＮGｕｅstBoｏｋ.Ｅntity;ﻫ

５

６namespace

NＧuesｔＢｏok.ＩＢLL

7{

8

///

〈sｕmmary＞

9

///

业务逻辑层接口-评论

１0

///

＜／sumｍaｒy＞11

pｕblic

inｔeｒｆａce

ＩCoｍmeｎtBLLﻫ１2

｛ﻫ13

／//

<sｕmmaｒｙ〉1４

／//

添加评论

15

///

＜/sｕmmary>1６

／//

＜param

nａme="commeｎt”〉新评论实体类<／paｒam>17

///

<rｅturｎs>是否成功＜/retｕrns>１８

bool

Ａdd（ComｍeｎtInfo

commｅｎt）；

1920

///

〈sｕmmarｙ〉21

///

删除评论ﻫ22

///

〈/suｍmａry〉23

///

〈paｒam

nａｍｅ＝"id"〉欲删除的评论的ID</paｒam〉24

///

<reｔurns〉是否成功</returｎs>２５

bｏol

Ｒemｏve(int

id）；

2６27

/／／

<summａry〉28

／//

取得指定留言的全部评论ﻫ29

///

</ｓumｍａry>30

///

<ｐaｒａm

ｎame="mｅsｓagｅId”>指定留言的ID<／pａram〉３1

／/／

〈reｔurnｓ>评论实体类集合＜/retｕrｎs〉３2

IList〈CommentInfo＞

ＧｅtＢyＭessage（inｔ

ｍｅsｓageId);

３3

}ﻫ3４}ﻫ

ﻫ

由业务逻辑确定数据访问操作

IＡdmiｎBLL需要的数据访问操作：插入管理员，删除管理员，更新管理员信息，按ＩD取得管理员信息，按登录名与密码取得管理员，取得全部管理员

IMesｓａｇｅBLL需要的数据访问操作：插入留言，删除留言，更新留言信息，按ＩD取得留言信息,按分页取得留言ﻫ

ＩComｍｅntBLL需要的数据访问操作：插入评论,删除评论,按留言取得全部评论

另外,添加管理员时需要验证是否存在同名管理员，所以需要添加一个“按登录名取得管理员”.

对以上操作进行整理,的如下接口操作：

ＩAｄｍｉnＤAL：Insert，Deletｅ，Updatｅ,GetByID，GetBｙNameAndPａssword，GetAlｌﻫ

ＩMessageDAL：Insert,Deｌeｔe，Updaｔe，GｅｔByIＤ，GeｔByPａｇeﻫ

IＣommｅｎtDAL:Inserｔ，Delete，GetByＭｅssage

这三个接口文件放在ＩDAL工程下，具体代码如下：ﻫﻫIAdmｉnDAL。cs:

1using

Syｓteｍ；ﻫ

２ｕｓiｎg

Systｅm.Collectｉons。Ｇeneric；

3ｕsing

Syｓｔem．Text；ﻫ

４usｉng

ＮGｕｅstBｏｏｋ.Entitｙ；ﻫ

5

６ｎａmespａce

NGuesｔBook．IDAL

7｛ﻫ

8

／//

〈suｍmarｙ>

９

//／

数据访问层接口-管理员ﻫ１0

//／

<／suｍmary〉１１

publｉc

inｔerfacｅ

IAdmiｎＤAL

12

｛

1３

／//

<sumｍary>１4

///

插入管理员

１５

／//

</suｍmａry〉16

//／

<ｐａｒam

name="admｉｎ">管理员实体类＜/parａm〉17

///

<returnｓ〉是否成功〈/reｔｕrｎｓ〉18

booｌ

Ｉｎsｅrｔ(AdminIｎｆｏ

admｉn）;ﻫ1920

///

<suｍｍａｒｙ＞21

／//

删除管理员ﻫ2２

///

<／ｓummary〉23

／//

〈ｐaram

name=＂id＂>欲删除的管理员的ＩD＜/ｐaram＞２４

/／/

〈returｎｓ>是否成功<／rｅtｕrns>２５

boｏl

Ｄeｌｅｔe（iｎｔ

id)；

２62７

//／

＜suｍmａrｙ〉28

///

更新管理员信息ﻫ2９

／//

＜/ｓumｍａry>30

／//

〈ｐａram

nａme＝"ａdmin＂>管理员实体类〈/paｒam〉３1

//／

〈ｒｅturns＞是否成功</returｎs〉3２

ｂｏol

Update(AdminInｆo

admiｎ）；ﻫ３3３４

///

＜sumｍary〉35

///

按ID取得管理员信息ﻫ３６

///

＜/suｍmary〉37

／//

<ｐaｒam

name=”id">管理员IＤ<／paｒaｍ〉３8

///

＜ｒeturns〉管理员实体类</retｕrns〉39

AdmｉｎInfo

GeｔＢyID（ｉnｔ

ｉd）；

4０４1

///

〈summａry〉４２

//／

按管理员名取得管理员信息

4３

/／/

〈/sumｍary＞44

／//

＜param

naｍe=＂name"〉管理员名〈／param〉45

／／/

<rｅtuｒｎｓ〉管理员实体类</retuｒns〉46

AdmiｎInfo

GｅｔByNａme（stｒiｎg

ｎame）；

4748

/／/

<suｍmary＞4９

///

按用户名及密码取得管理员信息

50

／//

</summａrｙ>51

/／/

<paｒaｍ

name="naｍe”＞用户名</paｒaｍ>52

／/／

＜param

namｅ＝”ｐassworｄ">密码</paraｍ＞53

///

<rｅｔurｎs＞管理员实体类,不存在时返回nuｌl<／ｒetuｒns>54

AｄmｉnInfｏ

ＧetＢyNａmｅAｎｄPasｓwoｒｄ（strｉnｇ

nａme,ｓtring

paｓsword）;

555６

／//

〈summarｙ>5７

／/／

取得全部管理员信息

58

//／

〈／summａry>59

/／/

＜rｅｔｕrns〉管理员实体类集合＜/ｒeturｎs〉60

ILiｓｔ<ＡｄmiｎInfo>

GetAll（）;ﻫ61

｝

62｝

IMｅssageDＡＬ.ｃs：

１usiｎｇ

Syｓtem;

2using

Sysｔem．Colｌectionｓ。Gｅｎeｒｉc;

3using

Ｓｙstｅm.Text；ﻫ

４usinｇ

NGｕｅstBｏｏk。Enｔity；

5

6namｅspａce

NＧuｅｓｔBｏｏk.ＩDAL

7{ﻫ

８

/／/

<summary〉

9

/／/

数据访问层接口－留言ﻫ10

//／

</ｓummary〉11

pｕblｉc

ｉnteｒｆａce

IMessageDALﻫ12

｛

13

/／／

〈summaｒｙ＞14

／／/

插入留言

15

///

〈/ｓummａry〉１6

／//

<parａm

name="ｍesｓage">留言实体类</parａm>1７

／／/

〈reｔurnｓ＞是否成功〈／returns>1８

booｌ

Inｓert（ＭeｓsａgeInfo

meｓsａｇe）；

１9２０

///

＜ｓuｍmary>２1

///

删除留言

22

/／/

＜／ｓummary>２３

//／

〈ｐaraｍ

namｅ=”id">欲删除的留言的IＤ</ｐａram〉２4

///

〈retｕrｎs〉是否成功〈／retuｒns〉25

bｏｏl

Delete（ｉnt

ｉd);

262７

///

＜summary〉28

／／／

更新留言信息ﻫ2９

///

</summａry〉３０

///

<pａram

ｎaｍe＝"ｍessage”〉留言实体类〈/ｐａｒam＞3１

/／/

〈retｕrns〉是否成功〈/returns>32

bool

Uｐｄａte(MｅssagｅＩnｆo

message）;

333４

///

＜ｓummary〉35

／／/

按ID取得留言信息ﻫ3６

/／/

<／summary＞37

/／/

〈param

naｍe="ｉｄ”〉留言ＩD〈/ｐaram〉38

///

＜rｅtuｒns>留言实体类〈/rｅｔurnｓ>3９

MessaｇｅIｎfｏ

GeｔByID（int

id）；ﻫ404１

///

<suｍｍarｙ〉42

///

按分页取得留言信息ﻫ43

///

＜/ｓummａry>44

//／

〈paｒａm

nａme＝＂ｐagｅＳｉze"〉每页显示几条留言<／ｐaraｍ〉4５

／/／

〈ｐaｒam

namｅ=＂pａgeNumber"〉当前页码＜/pａram>４6

／/／

<ｒeturns>留言实体类集合</reｔurｎs＞4７

ＩList＜MｅssａgｅInfo>

GｅtＢｙPａｇe（int

ｐaｇｅSize，int

pａgeNumber）；

4８

}

49｝ﻫIComｍentDＡL。cs：

1uｓｉng

Ｓysteｍ；

2ｕsing

System.Cｏlleｃｔions．Geｎeric;

３ｕsing

System．Teｘt;

4usiｎg

NGueｓtBｏok.Enｔitｙ；ﻫ

5

6nameｓｐaｃe

NＧuesｔBook.IＤALﻫ

7｛

８

///

〈summaｒy＞

9

///

数据访问层接口－评论ﻫ1０

///

</ｓuｍｍarｙ>11

pubｌic

inteｒｆace

ICommenｔDAＬﻫ1２

｛

１3

///

＜ｓummａrｙ>１4

///

插入评论

15

／/／

〈/summaｒy>16

///

〈ｐaram

namｅ="ｃommｅnt"〉评论实体类〈/paｒaｍ＞17

///

〈rｅtｕrｎs＞是否成功</retｕrns〉18

bool

Ｉnｓerｔ（CｏmmentInfｏ

commeｎｔ）；

192０

///

〈ｓummaｒｙ〉２1

///

删除评论ﻫ2２

///

〈/ｓumｍａry>2３

／//

<paｒam

ｎaｍｅ=”iｄ”〉欲删除的评论的ID<／param>2４

//／

〈returnｓ>是否成功</rｅturns〉２５

ｂoｏｌ

Delete(inｔ

ｉd）;

26２7

//／

〈sｕmｍarｙ〉28

///

取得指定留言的全部评论

2９

／//

〈/ｓummary〉３0

///

〈param

namｅ=”messａgeId”>指定留言的ID</parａm＞31

///

＜ｒetｕｒnｓ〉评论实体类集合</rｅｔurnｓ＞32

IＬisｔ〈ＣommｅntIｎfｏ〉

GｅtByMessage(inｔ

mesｓagｅId)；

33

｝

34｝我们设计的分层架构，层与层之间应该是松散耦合的。因为是单向单一调用,所以，这里的“松散耦合”实际是指上层类不能具体依赖于下层类，而应该依赖于下层提供的一个接口.这样，上层类不能直接实例化下层中的类，而只持有接口，至于接口所指变量最终究竟是哪一个类，则由依赖注入机制决定。ﻫﻫ

之所以这样做,是为了实现层与层之间的“可替换”式设计，例如，现在需要换一种方式实现数据访问层，只要这个实现遵循了前面定义的数据访问层接口,业务逻辑层和表示层不需要做任何改动，只需要改一下配置文件系统即可正常运行.另外，基于这种结构的系统，还可以实现并行开发。即不同开发人员可以专注于自己的层次,只有接口被定义好了，开发出来的东西就可以无缝连接。ﻫ

在J2EE平台上，主要使用Sprｉng框架实现依赖注入。这里，我们将自己做一个依赖注入容器。

ﻫ

依赖注入的理论基础是ＡｂstrａｃtFactory设计模式，这里结合具体实例简单介绍一下。ﻫ

上图以数据访问层为例，展示了AbstractFactoｒy模式的应用。如图,现假设有针对Acｃess和SQLSｅｒveｒ两种数据库的数据访问层,它们都实现了数据访问层接口。每个数据访问层有自己的工厂，所有工厂都实现自IＤALFactoｒy接口。而客户类(这里就是业务逻辑层类)仅与工厂接口、数据访问层接口耦合，而与具体类无关,这样，只要通过配置文件确定实例化哪个工厂，就可以得到不同的数据访问层.

ﻫ

然而,这种设计虽然可行，但是代码比较冗余，因为这样需要为数据访问层的每一个实现编写一个工厂，业务逻辑层也一样。在以前,我们毫无办法,但是，。ＮET平台引入的反射机制,给我们提供了一种解决方案。使用反射,每个层只需要一个工厂,然后通过从配置文件中读出程序集的名称,动态加载相应类。另外,为了提高依赖注入机制的效率,这里引入缓存机制。下面来看具体实现。

ﻫ

配置

首先，需要在Web工程的Web.confｉg文件的〈ａppSｅttiｎgｓ〉节点下添加如下两个项：

<adｄkey=＂DAＬ＂value=＂”/＞ﻫ

〈adｄkey=”BLL"value=""/〉

这两个配置选项分别存储要应用的数据访问和也业务逻辑层的程序集名称。ｖalｕe目前是空，是因为目前还没有各个层次的具体实现。

ﻫ

实现缓存操作辅助类

为实现缓存操作，我们将缓存操作封装成一个辅助类，放在Ｕtｉｌity工程下，具体代码如下:

ﻫCａｃheAｃcess.ｃs：

封装依赖注入代码

因为很多依赖注入代码非常相似,为了减少重复性代码，我们将可复用的代码先封装在一个类中。具体代码如下(这个类放在Factoｒｙ工程下）:

ＤepenｄeｎcyInｊecｔor．cｓ：

１uｓing

System;

2usｉng

Sysｔｅm。Ｗｅb；ﻫ

3using

System.Ｗeb.Cachｉng;ﻫ

4

5nameｓｐace

NGuｅstＢooｋ．Utiｌiｔyﻫ

6｛

7

///

<summａry〉

８

／//

辅助类，用于缓存操作ﻫ

9

///

〈/sｕｍｍａry〉10

public

sｅａled

clａss

CaｃｈeＡcceｓs

11

{ﻫ１２

//／

<summａrｙ〉13

//／

将对象加入到缓存中ﻫ１4

///

〈/suｍmary〉1５

///

＜pａｒam

naｍｅ=”caｃｈeKey＂〉缓存键＜/pａｒａm〉16

///

＜paｒａm

nａｍｅ＝"ｃacheOｂjｅct＂〉缓存对象</parａm>17

//／

〈pａram

ｎame="dｅpeｎdｅncy"〉缓存依赖项＜/paｒａm〉18

public

staｔic

void

SavｅToCacｈｅ（striｎg

cacheＫｅy，

ｏbjｅcｔ

caｃheObject,

CaｃheDｅpｅnｄenｃｙ

dependeｎcy）ﻫ１9

｛

20

Cache

ｃachｅ

＝

HｔｔpRuntiｍe。Ｃａche；

21

ｃａchｅ。Iｎsert（cacheKey,

cacheObjeｃｔ,

ｄependencｙ）；

22

｝ﻫ23２４

///

<ｓｕmｍarｙ>２5

/／/

从缓存中取得对象,不存在则返回ｎull

2６

///

〈/sumｍaｒｙ＞27

///

〈pａram

nａme=＂ｃａchｅＫｅy"〉缓存键</param＞28

///

<returｎs>获取的缓存对象</rｅturns>29

publiｃ

sｔatiｃ

objｅｃt

GeｔFrｏmCacｈe（stｒinｇ

caｃｈeKeｙ）ﻫ30

｛ﻫ31

Cache

ｃache

=

HtｔpRuntｉme。Cachｅ；ﻫ3233

reｔurn

ｃａｃhe［cacheＫｅy］；ﻫ34

｝

３5

｝ﻫ3６｝

1using

Sｙsteｍ；ﻫ

2ｕsing

Ｓysteｍ。Cｏnfiguｒatiｏn；ﻫ

3using

System．Reflｅｃtion；ﻫ

4using

Ｓystem.Ｗｅb；ﻫ

５using

Ｓysteｍ．Web．Cａcｈiｎg;

6using

NGｕestＢook．Ｕｔｉlitｙ；ﻫ

7

8ｎａｍｅspace

NGuesｔＢooｋ。Fａctoryﻫ

9｛ﻫ10

///

〈suｍmaｒｙ〉1１

///

依赖注入提供者ﻫ12

//／

使用反射机制实现ﻫ13

／//

＜/sｕmmａrｙ>１4

public

ｓeaｌｅd

ｃｌass

ＤepｅndencyＩｎjectorﻫ15

｛ﻫ16

／／/

＜ｓｕmmary＞17

／//

取得数据访问层对象ﻫ18

//／

首先检查缓存中是否存在，如果不存在，则利用反射机制返回对象

１9

／//

＜/ｓuｍｍarｙ〉2０

///

〈pａram

ｎame=”ｃｌａssＮaｍｅ"＞数据访问类名称</param〉2１

///

<returｎs>数据访问层对象〈/rｅtuｒns〉２２

pｕblic

sｔａtic

object

GｅtDALObject（string

classNａmｅ)

23

｛ﻫ２４

///

〈ｓｕmmａry＞2５

//／

取得数据访问层名称，首先检查缓存，不存在则到配置文件中读取

26

//／

缓存依赖项为Wｅb．Confiｇ文件

2７

/／/

〈/summarｙ>２8

ｏbject

dａl

=

CachｅAcｃｅss.ＧetFromＣache(”DＡL");ﻫ29

ｉf

(daｌ

=＝

ｎｕll)

30

｛ﻫ31

ＣａｃｈeDeｐｅndeｎｃy

ｆileDepｅndency

=

new

CacｈｅDepｅｎｄeｎcｙ（HttpCoｎtext.Ｃurrｅｎt。Ｓerｖer.ＭaｐPatｈ（”Weｂ．Coｎfig"))；

32

dal

=

ConfiguraｔｉoｎManａger.AppSｅttings［"ＤAL”］；ﻫ33

CacheAccess.SａveToCacｈe(”DＡL＂，

ｄaｌ，

fｉleDepeｎｄenｃy);

3４

}

3５36

／//

＜sｕmｍary＞３7

///

取得数据访问层对象ﻫ38

///

〈/summary＞3９

strｉng

dalNａme

=

（sｔｒing)ｄal；ﻫ40

sｔriｎg

ｆｕllClaｓｓＮａｍe

=

ｄalName

+

"。"

+

cｌassNaｍe；

４1

ｏbjecｔ

dalOｂjｅcｔ

=

CａｃheＡｃceｓs.GetＦｒomCache（ｃlassＮａme）;ﻫ42

if

（dａlObject

==

nulｌ)ﻫ４3

｛

44

ＣacheＤependencｙ

fileDｅｐｅndency

=

nｅw

CacｈeDｅpendency(HtｔpContｅxt.Currｅnt．Ｓｅrveｒ．ＭａpＰath（"Ｗeb.Coｎfiｇ"））；

４5

dalObjｅct

＝

Assembｌy。Lｏａd（dａlName）。ＣreaｔｅＩnstａnce（ｆuｌlＣlassNamｅ);ﻫ46

CaｃheAccess.SaveTｏCａｃhe（clａssName,

ｄalObｊｅct,

ｆileDeｐeｎdencｙ);ﻫ47

｝ﻫ4849

retｕｒn

daｌＯbjｅct;ﻫ5０

｝

５152

／//

〈suｍmary〉53

／//

取得业务逻辑层对象

５4

///

首先检查缓存中是否存在，如果不存在,则利用反射机制返回对象ﻫ5５

///

〈/sumｍarｙ〉56

///

＜ｐａram

name=”ｃlａｓsNaｍe＂>业务逻辑类名称<／ｐarａm＞57

///

<ｒeｔurns〉业务逻辑层对象</ｒeｔurns>58

pｕｂlｉc

sｔａtic

object

GeｔＢLLObject(ｓtrｉng

clａssName）

59

{

6０

/／／

<summary＞6１

///

取得业务逻辑层名称，首先检查缓存，不存在则到配置文件中读取ﻫ62

///

缓存依赖项为Web。Ｃonｆiｇ文件ﻫ63

／//

〈/summary>64

ｏbjｅct

ｂll

=

CaｃheＡccｅsｓ.GetFrｏmCａｃｈe(”BLＬ");ﻫ65

iｆ

（ｂll

=＝

null）

66

{

67

CaｃheDepｅnｄency

fｉｌeDeｐendeｎｃy

=

ｎｅw

CａcheDepenｄenｃy（ＨttpContext.Curreｎt.Server.MaｐPaｔｈ（"Web.Cｏnfｉg"));

68

bｌl

＝

ＣonｆiｇurａtiｏｎMaｎａｇｅr．ＡｐpSeｔtings[”BＬL＂]；ﻫ69

CaｃheＡcｃｅss.SaveToCache（＂BLL"，

bll，

ｆiｌeDependenｃｙ）；

70

}

7１７2

///

＜ｓｕｍｍaｒy>73

//／

取得业务逻辑层对象

７4

／／/

＜／summarｙ>75

ｓtrinｇ

bllＮame

=

（strinｇ)blｌ;ﻫ76

ｓtｒｉnｇ

fullＣlａsｓＮame

=

bｌｌＮａme

＋

”．＂

+

clａssNaｍe；

７7

objecｔ

bllObject

＝

CacheAｃｃeｓｓ。GetFromＣａche(ｃlａｓsNamｅ）;

７8

if

（blｌOｂject

==

nuｌl）

7９

｛ﻫ80

CachｅDepenｄency

filｅＤepｅndenｃy

=

nｅw

CaｃｈeDｅpendenｃy（HｔtpContext。Ｃurｒent.Ｓｅrｖer．ＭapＰaｔｈ("Web.Cｏnfig＂））；

81

bllObｊeｃt

＝

Assembly．Lｏａd(bllNaｍe).CrｅateIｎstaｎce（ｆｕｌlClassName）；

82

CaｃhｅＡcｃｅsｓ．SａｖeToCａche（class