深入浅出C#三层架构

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

深入浅出C#三层架构

本文用一个示例来介绍如何建设一个三层架构的项目,并说明项目中各个文件所处的层次与作用。写本文的目的,不是为了说明自己的这个方法有多对,而是希望给那些初学三层架构却不知从何入手的朋友提供一点帮助。因为网上的文章,大多是注重理论的介绍,而忽略了具体的实践应用,或者有示例但讲得不透彻。导致看了之后,理论上又学习了一遍,但还是不知道代码怎么写。所以想从这个方面入手写一下,让从来没做过三层架构的初学者也能照猫画虎,写出代码来。文中的代码是伪代码,仅用来阐明思路。

正文:

一提三层架构,大家都知道是表现层(UI),业务逻辑层(BLL)和数据访问层(DAL),而且每层如何细分也都有很多的方法。但具体代码怎么写,到底那些文件算在哪一层,却是模模糊糊的。下面用一个简单的例子来带领大家实战三层架构的项目,这个例子只有一个功能,就是用户的简单管理。

首先建立一个空白解决方案,添加如下项目及文件

1、添加 Web Application项目,命名为UI,新建Web Form类型文件User.aspx(含User.aspx.cs)

2、添加ClassLibrary项目,命名为BLL,新建Class类型文件UserBLL.cs

3、添加ClassLibrary项目,命名为DAL,新建Class类型文件UserDAL.cs。添加SQLHelper引用。(这个是微软的数据访问类,也可以不用,直接编写所有的数据访问代码。我一般用自己写的数据访问类DataAccessHelper )。

4、添加ClassLibrary项目,命名为Model,新建Class类型文件UserModel.cs

5、添加ClassLibrary项目,命名为IDAL,新建Interface类型文件IUserDAL.cs

6、添加ClassLibrary项目,命名为ClassFactory

相信大家已经看出来了,这个和Petshop的示例没什么区别,而且更简单,因为在下也是通过Petshop学习三层架构的。但一些朋友对于这几个项目所处的层次,以及它们之间的关系,可能比较模糊,这里逐个说明一下:

1、User.aspx和User.aspx.cs

这两个文件(以及文件所属的项目,下面也是如此,不再重复强调了)都属于表现层部分。User.aspx比较好理解,因为它就是显示页面了。User.aspx.cs有些人觉得不应该算,而是要划到业务逻辑层中去。如果不做分层的话,那么让User.aspx.cs来处理业务逻辑,甚至操作数据库都没什么问题,但是做分层的话,

这样就不应该了。在分层结构中,User.aspx.cs仅应该处理与显示有关的内容,其它部分都不应该涉及。

举例:我们实现用列表方式显示用户的功能,那么提取信息的工作是由BLL来做的,UI(本例中是User.aspx.cs)调用BLL得到UserInfo后,通过代码绑定到User.aspx的数据控件上,就实现了列表的显示。在此过程中User.aspx.cs对UI没有起到什么作用,仅是用来传递数据,而且因为实际编码中大部分情况都是如此的实现,所以使有些人觉得User.aspx.cs不应该算UI,而应该并入BLL负责逻辑处理。继续往下看,这时提出了一个新需求,要求在每个用户的前面加一个图标,生动地表现出用户的性别,而且不满18岁的用儿童图标表示。这个需求的实现,就轮到User.aspx.cs来做了,这种情况下User.aspx.cs 才算有了真正的用途。

2、NewBLL.cs

添加如下方法:

public IList GetUsers():返回所有的用户信息列表

public UserInfo GetUser(int UserId):返回指定用户的详细信息

public bool AddUser(UserInfo User):新增用户信息

public bool ChangeUser(UserInfo User):更新用户信息

public void RemoveUser(int UserId):移除用户信息

此文件就属于业务逻辑层了,专门用来处理与业务逻辑有关的操作。可能有很多人觉得这一层唯一的用途,就是把表现层传过来的数据转发给数据层。这种情况确实很多,但这只能说明项目比较简单,或者项目本身与业务的关系结合的不紧密(比如当前比较流行的MIS),所以造成业务层无事可做,只起到了一个转发的作用。但这不代表业务层可有可无,随着项目的增大,或者业务关系比较多,业务层就会体现出它的作用来了。

此处最可能造成错误的,就是把数据操作代码划在了业务逻辑层,而把数据库作为了数据访问层。

举例:有些朋友感觉BLL层意义不大,只是将DAL的数据提上来就转发给了UI,而未作任何处理。看一下这个例子

BLL层

SelectUser(UserInfo userInfo)根据传入的username或email得到用户详细信息。

IsExist(UserInfo userInfo)判断指定的username或email是否存在。

然后DAL也相应提供方法共BLL调用

SelectUser(UserInfo userInfo)

IsExist(UserInfo userInfo)

这样BLL确实只起到了一个传递的作用。

但如果这样做:

BLL.IsExist(Userinfo userinfo)

{

UerInfo user = DAL.SelectUser(User);

return (userInfo.Id != null);

}

那么DAL就无需实现IsExist()方法了,BLL中也就有了逻辑处理的代码。

3、UserModel.cs

实体类,这个东西,大家可能觉得不好分层。包括我以前在内,是这样理解的:

UIßàModelßàBLLßàModelßàDAL,如此则认为Model在各层之间起到了一个数据传输的桥梁作用。不过在这里,我们不是把事情想简单,而是想复杂了。

相关文档
最新文档