基于.NET平台的分层架构实战(完整资料)

基于.NET平台的分层架构实战(完整资料）(可以直接使用，可编辑优秀版资料，欢迎下载）

通过浏览博客园的文章发现，很多朋友对分层架构特别感兴趣，刚好我刚做完的毕业设计就是专门研究．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。基于.NET平台的分层架构实战(完整资料）(可以直接使用，可编辑优秀版资料，欢迎下载）在实际的项目中,需求分析和数据库的设计是很重要的一个环节，这个环节会直接影响项目的开发过程和质量。实际中，这个环节不但需要系统分析师、软件工程师等计算机方面的专家,还需要相关领域的领域专家参与才能完成。ﻫﻫ

但是，在这个文章系列中,所要使用的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（className,

bｌｌObjｅｃt,

ｆileＤeｐendeｎcy);ﻫ83

｝ﻫ84８5

reｔuｒn

blｌObｊect；

８6

｝

8７

｝ﻫ88｝

实现工厂

下面使用两个辅助类，实现数据访问层工厂和业务逻辑层工厂.ﻫﻫDＡＬFactorｙ。ｃs

１using

System;ﻫ

２usinｇ

NGueｓtBook．IDAL；ﻫ

3

4ｎamespace

NGｕeｓtBoｏｋ.Fａcｔｏryﻫ

5｛

6

///

〈sｕmmary>

7

///

数据访问层工厂,用于获取相应的数据访问层对象

8

///

使用Abｓｔract

Facｔory设计模式+Facace设计模式＋反射机制＋缓存机制设计

9

///

<／suｍmaｒy＞１0

public

sealｅd

ｃlａsｓ

DAＬＦａｃtoryﻫ11

{

12

///

＜summarｙ＞１3

／//

获取管理员数据访问层对象ﻫ14

///

＜/ｓummaｒy>15

／／/

<reｔurns＞管理员数据访问层对象〈/ｒetｕrｎs〉16

publiｃ

ｓｔatic

ＩAｄminDAＬ

CreaｔｅＡdminＤAL（）ﻫ17

｛ﻫ18

ｒｅturｎ

（IAdmｉnDAL)DepｅnｄencyInｊｅcｔor．GｅtDＡLObjecｔ("AdmiｎＤAL”)；ﻫ１9

｝ﻫ２0２１

／/／

〈sｕｍｍarｙ＞22

／／／

获取留言数据访问层对象

23

//／

<／sumｍary〉24

///

<ｒeturns>留言数据访问层对象＜/retuｒns〉２５

publｉc

static

IＭessaｇeDAL

CrｅａteMeｓｓaｇeDAL()

26

｛ﻫ２7

returｎ

（IMｅｓsａgeDAＬ）DeｐendｅｎｃｙIｎjectｏr．GetＤALObject（"MessageDＡＬ＂）；ﻫ28

｝ﻫ２93０

///

<sumｍaｒy>３1

///

获取评论数据访问层对象

32

///

〈/sｕｍmarｙ＞33

///

<returns＞评论数据访问层对象＜/retｕrns〉34

ｐuｂｌｉc

ｓｔatic

ICommenｔＤAＬ

CreａteCommenｔＤAL（)

35

｛

3６

rｅturn

(ＩComｍentＤＡＬ）DepenｄeｎcyIｎjector．ＧｅｔDAＬＯbjecｔ（＂CommentＤAL”)；ﻫ37

}

３8

}

39｝ﻫBLLＦaｃtorｙ.cｓ

1uｓiｎｇ

Sｙsｔem;

2ｕｓｉnｇ

ＮGueｓtBooｋ。IBLＬ；

3

4namｅｓｐaｃe

ＮGuｅsｔBooｋ。Fａctoryﻫ

5｛ﻫ

6

／//

＜sｕｍｍary〉

7

///

业务逻辑层工厂，用于获取相应的业务逻辑层对象

8

／//

使用Aｂsｔraｃt

Factorｙ设计模式+Facaｃe设计模式+反射机制+缓存机制设计ﻫ

9

///

＜/suｍmary>10

pｕbｌｉc

ｓealｅd

clasｓ

BLLＦactｏryﻫ11

{ﻫ12

/／/

＜ｓumｍaｒy＞１3

／//

获取管理员业务逻辑层对象ﻫ１4

///

</summａry>1５

//／

〈retuｒｎs〉管理员业务逻辑层对象〈/reｔuｒｎs>１６

public

ｓtatｉc

IＡdminBLL

ＣreateＡdminBＬＬ（）

17

{ﻫ１8

reｔurｎ

（IAｄminBLＬ）ＤepeｎdencｙInjecｔoｒ．GetBＬＬObjｅct(”AdminBＬL”）;

1９

｝ﻫ202１

／//

<ｓummaｒy〉２2

／//

获取留言业务逻辑层对象ﻫ23

///

</summaｒy>24

／//

＜returns〉留言业务逻辑层对象〈/returns>25

pubｌic

static

ＩMesｓａgeＢLＬ

ＣrｅateMessaｇｅＢLL（)

26

｛

２7

retｕｒn

(IMｅssageBLL）ＤｅｐeｎdenｃyＩnjｅctor。GetBＬLＯｂjeｃt（"MeｓsageBLL”）;

２８

｝ﻫ293０

///

<sｕmmary>31

/／/

获取评论业务逻辑层对象

３2

//／

〈/suｍmary〉3３

／／/

〈ｒeturｎs＞评论业务逻辑层对象</ｒeturns>3４

pｕblic

statｉc

ICoｍmentＢLＬ

CｒeaｔeCommentBLＬ（)

35

｛ﻫ3６

reｔuｒｎ

(ICommentBLL)DｅpｅndｅnｃyIｎjector．GetBLLOｂject（"ComｍeｎtBLL"）;ﻫ３7

}

38

}

39｝经过上面篇文章的介绍，整个系统的框架算是基本搭建完了,下面，我们要具体实现各个层次。关于数据访问层的实现，我准备讨论三种实现方式,这一篇文章讨论第一种：Aｃcess+动态生成SＱＬ。

顾名思义，这种实现将使用Accｅss作为后台数据库,而操作方式也是最基本的使用ＳＱL命令.ﻫ

在具体编写实现代码之前，我们需要做一些准备工作：

ﻫ

第一步，我们要将Aｃｃeｓs数据库搭建完成，具体做法如下.

在Web工程下新建一个文件夹，命名为AccessDａta，并在其中新建一个ｍdb文件（即Access数据库文件），按照前面介绍过的数据库设计构架，将数据表及表间关系建好，这里不再赘述。

第二步，我们要进行一些配置。

打开Web工程下的Wｅb.confiｇ文件，在其中的apｐSetｔiｎgs节点下，添加如下键值:

<addkey="AccｅｓsCｏnnectionSｔｒｉｎg"valｕｅ="Proviｄｅr=Micrｏsoft.Ｊet。OＬEDB．4。０;DatａＳource={ＤBPatｈ}"/>ﻫ

<aｄdkｅｙ="AｃceｓsＰaｔh”value="~/AcｃessData/AccessDaｔabａｓe.mdb"／>ﻫ

第一条为Access的连接字符串，第二条为Acｃess数据库文件的路径，其中“~”表示网站根目录。

ﻫ

第三步，新建一个工程.ﻫ

我们要新建一个工程AccessDAL,用来存放Aｃｃｅsｓ数据访问层的代码。ﻫ

准备工作做完了，现在来实现具体的代码.ﻫ

1.编写数据访问助手类

因为很多数据访问操作流程很相似，所以，这里将一些可复用的代码抽取出来，编写成助手类，以此减少代码量，提高代码复用性.ﻫ

这个助手类放在AcｃesｓＤAL下，叫AccｅｓｓDALHelper,主要负责Ａcceｓs数据库的访问。它包括三个方法：ﻫ

GeｔConnｅctｉonStriｎg:从配置文件中读取配置项,组合成连接字符串.

ＥxecｕｔeSQLＮonＱｕｅry：执行指定SＱL语句，不返回任何值，一般用于Ｉnsｅｒt，Deｌete,Updatｅ命令.

EｘecuｔeSQLＤａtaReaｄer：执行SQL语句返回查询结果，一般用于Select命令。ﻫ

具体代码如下:

ﻫAccｅssＤAＬHｅｌpeｒ。ｃs:ﻫ

２。实现具体的数据访问操作类ﻫ

因为前面已经定义了数据访问层接口,所以实现数据访问操作类就是很机械的工作了。下面仅以Admin的数据访问操作类为例：ﻫﻫAdminDAL:

1usinｇ

Ｓｙstem；

2uｓiｎg

Ｓｙsｔｅm．Wｅb；

3using

Sysｔeｍ。Web。Caching；ﻫ

4uｓing

Sｙｓtem．Cｏnfｉguration；

５uｓing

System．Ｄata；ﻫ

6ｕsiｎg

Sｙstem.Datａ.OｌeＤb；ﻫ

7usiｎg

NGuｅstBoｏk.Utilitｙ;ﻫ

８

9naｍesｐace

ＮGueｓtBoｏk.AｃcesｓＤAL

1０｛

11

／//

<sumｍary>12

//／

Aｃcｅss数据库操作助手ﻫ13

///

〈／sｕmmarｙ〉1４

publｉc

sealed

claｓs

AｃceｓsDALHeｌper

15

｛ﻫ16