《三层架构应用总结.docx》由会员分享，可在线阅读，更多相关《三层架构应用总结.docx（10页珍藏版）》请在课桌文档上搜索。
1、ASRNET三层架构应用总结与ASP相比ASP.NET在Web应用开发上无疑更简洁，更有效率。Web开发大部分还是围围着数据操作，建立数据库存储数据，编写代码访问和修改数据，设计界面采集和呈现数据。走过Aspmei学习入门阶段后，真正开头着手开发一个Web项目时，才发觉错综简单的数据与关联根本就不是SqlDataSource和AccessDaUiSource数据源控件能简洁解决的，而恰恰是被忽视了的一个ObjeCtDaIaSOUrCe数据源控件才是真正踏入开发门槛的关键，由此也对三层架构模式有了初步体验。一.ASP.NET三层架构介绍设计模式中的分层架构（可以参考一下J2EE中MVC模式）实现
2、了各司其职，互不干涉，所以假如一旦哪一层的需求发生了变化，就只需要更改相应的层中的代码而不会影响到其它层中的代码。这样就能更好的实现开发中的分工，有利于组件的重用。所以这些年关于模式的讨论有很多成果，应用也很广泛。一个好的模式在程序开发和后期维护中作用重大。ASP.NET三层架构自底向上分为：数据访问层（DAL）,业务规律层（BLL）和表示层（PL）。数据访问层（DAL）：使用了一个强类型的DataSet作为数据访问层，只是单纯的对数据进行增，删，改，查询和推断存在等等较通用的数据访问方法（由SQL语句来供应），不应当有“事务”存在。业务规律层（BLL）：业务规律层是在数据访问层和表示层之间进
3、行数据交换的桥梁，按业务需求调用数据访问层中的方法组合，集合了各种业务规章到一个BLL中，例如通过条件进行推断的数据操作或“事务”处理。BLL都是以类库（CIaSSLibrary）的形式来实现的。表示层（PL）：表示层是为客户供应用于交互的应用服务图形界面，关心用户理解和高效地定位应用服务，呈现业务规律层中传递的数据，用ASP.NET页面来实现。二.三层架构应用实现随着ASP.NET的不断升级，可以很便利的使用ASP.NET来构建B/S三层架构的应用程序，下而以“老师业务信息管理系统”项目中的部分例子来演示如何使用ASP.NET2.0和SQLServer2005数据库来构建一个三层架构的应用程
4、序。1 .创建数据库打开SQLSerVer2005,新建个数据库TeacherDb,建立如下所示结构的两个表Personlnfo”和JoblnfoO两表以PerSonlDNUmber作为关联字段，存储18位身份证号码O表名：字段名PersonInfo类型说明基本信息表备注IDint主健，自增UserIDuniqueidentifier登录帐户IDTrueNamenvarchar(20)姓名PersonIDNumbernvarchar(18)身份证Sexnvarchar(1)性别“男”或“女”BirthDatedatetie出生日期Nationnvarchar(10)民族NativePlacen
5、varchar(50)籍贯Politynvarchar(10)政治面貌JoinPolityTimedatetie入党时间PersonImageUrlnvarchar(250)相片地址允许NULLTelephonenvarchar(50)联系电话MobiePhonenvarchar(50)手机号码Emailnvarchar(50)Email表名：JobInfo取业信息表字段名类型说明备注IDint主健，自增PersonIDNumbernvarchar(18)身份证号码Post1nvarchar(20)职务Post2nvarchar(20)职务2第二职务JoinTimedatetime参加工作时间
6、COUntryWorkedTieint农村年限MasteSubjectnvarchar(20)学科SecondSubjectnvarchar(20)兼职学科SchoolPhasenvarchar(10)学段MotherClassTimeint班主任年限SchoolIDint所在学校代码InPositionreal是否在职2 .创建数据访问层在开头创建数据访问层(DAL)之前，首先需要创建一个网站，配置好数据库链接。第一步：创建一个Web项目，配置数据库连接打开ViSUaISmdiO2005(以下简称VS2005)集成开发环境，首先创建个C#语言的ASP.NET网站，并将其命名为WebSite,
7、设置位置(LoCatiOn)列表的选项为文件系统(FileSystem),然后选这一个放置这个网站的文件夹，然后选择编程语言为C#。ViSUalSmdi。会为你生成个新的网站，同时生成个名为Default.aspx的网页，和一个App_Data文件夹。其次步：创建数据访问层，配置数据库连接接卜.来创建数据访问层，添加一个强类型的DataSet0在解决方案管理器里的项目节点上按右鼠标，选择“添加新项，在模板列单里选择数据集，将其命名为DataSetlxscL接下来会消失TabIeAdpater”配置向导的窗口，选择数据库服务器，设置好各项参数，并依据提示逐步完成。需要留意：1 .指定连接的数据库
8、字符串，并选择将连接字符串保存到Web.coZig文件中去。2 .命令类型选择“使用SQL语句”，通过“高级选项”选择“生成InSert、UPdate和DeIete语句”，通过“查询生成器生成要装载数据的Select语句:并为方法命名。选择要生成的方法_TableAdapter方法在应用程序和数据库之间加载和保存数据。要将些方法添加到TabieAdaPter?Pr蓄充DataTable(X)创建一个方法，让其使用DataTable或数据集作为参数，并执行在上一页中输入的SQL语句或SELECT存储过程。方法名)：PinP返回DataTable)创建一个方法，让其返回一个新的DataTabIe并
9、用在上一页中输入的SQL语句或SELECT存储过程的结果进行埴充方法名称也)：IGetPerSonS-“创建方法以将更新直接发送到数得库(GeiierateDBDirectiethods)(U)创建可进行调用以将单个行更改直接发送到数据库的Insert、Update和Delete方法. 11完成但)资料二引言：木文不是从理论的角度来研讨三层架构，而是用一个示例来介绍如何建设一个三层架构的项目，并说明项目中各个文件所处的层次与作用。写本文的目的，不是为了说明自己的这个方法有多对，别人的确定不对，而是盼望给那些初学三层架构却不知从何入手的伴侣供应一点关心。由于网上的文章，大多是留意理论的介绍，而忽
10、视了具体的实践应用，或者有示例但讲得不透彻。导致看了之后，理论上又学习了一遍，但还是不知道代码怎么写。所以想从这个方面入手写一下，让从来没做过三层架构的初学者也能照猫画虎，写出代码来。文章表述的是笔者个人对三层架构的熟悉，确定有很多不足的地方，欢迎大家指正，小弟也会依据反馈来修改这篇文章。文中的代码是伪代码，仅用来阐明思路。正文:一提三层架构，大家都知道是表现层(UI),业务规律层(BLL)和数据访问层(DAL),而且每层如何细分也都有很多的方法。但具体代码怎么写，究竟那些文件算在哪一层，却是模模糊糊的。下面用一个简洁的例子来带领大家实战三层架构的项目，这个例子只有一个功能，就是用户的简洁管理
11、。首先建立一个空臼解决方案，添加如下项目及文件1、添加ASRNETWebApplication项目，命名为UL新建WebForm类型文件Usenaspx(含User.aspx.cs)2、添加ClaSSLibrary项目，命名为BLL,新建CIaSS类型文件USerBLL.cs3、添加ClassLibrary项目，命名为DAL,新建Class类型文件USerDAL.cs。添加SQLHelper引用。(这个是微软的数据访问类，也可以不用，直接编写全部的数据访问代码。我一般用自己写的数据访问类DataAccessHelper).,4添加ClassLibrary项目，命名为Model,新建Class类
12、型文件UserModeLcs5、添加ClassLibrary项目，命名为IDAL,新建Interface类型文件IUserDAL.cs6、添加ClassLibrary项目，命名为ClassFactory信任大家已经看出来了，这个和PetShoP的示例没什么区分，而且更简洁，由于在下也是通过PetSh叩学习三层架构的。但一些伴侣对于这几个项目所处的层次，以及它们之间的关系，可能比较模糊，这里逐个说明一下：1User.aspxUser.aspx.cs这两个文件(以及文件所属的项目，下面也是如此，不再重复强调了)都属于表现层部分。Usenaspx比较好理解，由于它就是显示页面了。User.aspx.
13、cs有些人觉得不应当算，而是要划到业务规律层中去。假如不做分层的话，那么让User.aspx.cs来处理业务规律，甚至操作数据库都没什么问题，但是做分层的话，这样就不应当了。在分层结构中，User.aspx.cs仅应当处理与显示有关的内容，其它部分都不应当涉及。举例：我们实现用列表方式显示用户的功能，那么提取信息的工作是由BLL来做的，UI(本例中是User.aspx.cs)调用BLL得到UserInfo后，通过代码绑定到User.aspx的数据控件上，就实现了列表的显示。在此过程中USer.aspx.es对Ul没有起到什么作用，仅是用来传递数据，而且由于实际编码中大部分状况都是如此的实现，所
14、以使有些人觉得User.aspx.cs不应当算UL而应当并入BLL负责规律处理。连续往下看，这时提出了一个新需求，要求在每个用户的前面加一个图标，生动地表现出用户的性别，而且不满18岁的用儿童图标表示。这个需求的实现，就轮到User.aspx.es来做了，这种状况下User.aspx.cs才算有了真正的用途。2、NewBLL.cs添加如下方法：publicIListGetUsers():返回全部的用户信息列表publicUserInfoGetUser(intUserid)：返回指定用户的具体信息publicboolAddUser(UserInfoUser)：新增用户信息publicboolCh
15、angeUser(UserInfoUser)：更新用户信息publicvoidRemoveUser(intUserid)：移除用户信息此文件就属于业务规律层了，特地用来处理与业务规律有关的操作。可能有很多人觉得这一层唯一的用途，就是把表现层传过来的数据转发给数据层。这种状况的确很多，但这只能说明项目比较简洁，或者项目本身与业务的关系结合的不紧密(比如当前比较流行的MlS),所以造成业务层无事可做，只起到了一个转发的作用。但这不代表业务层可有可无，随着项目的增大，或者业务关系比较多，业务层就会体现出它的作用来了。此处最可能造成错误的，就是把数据操作代码划在了业务规律层，而把数据库作为了数据访问层
16、。举例：有些伴侣感觉BLL层意义不大，只是将DAL的数据提上来就转发给了UI,而未作任何处理。看一下这个例子BLL层SelectUser(Userinfouserinfo)依据传入的username或email得到用户具体信息。IsExist(UserInfouserinfo)推断指定的username或email是否存在。然后DAL也相应供应方法共BLL调用SelectUser(UserInfbuserinfo)IsExist(UserInfouserinfo)这样BLL的确只起到了一个传递的作用。但假如这样做：BLLJsExist(UserinfoUserinfb)UerInfbuser=
17、DAL-SelectUser(User)；return(userlnfb.Id!=null);)那么DAL就无需实现ISEXiS1()方法了，BLL中也就有了规律处理的代码。3、UserModeLcs实体类，这个东西，大家可能觉得不好分层。包括我以前在内，是这样理解的：UlaModelaBLLaModelaDAL,如此则认为Model在各层之间起到了一个数据传输的桥梁作用。不过在这里，我们不是把事情想简洁，而是想简单了。MOdeI是什么？它什么也不是！它在三层架构中是可有可无的。它其实就是面对对象编程中最基本的东西：类。一个桌子是一个类，一条新闻也是一个类，ini、stringdoublie等
18、也是类，它仅仅是一个类而已。这样，ModeI在三层架构中的位置，和im,siring等变量的地位就一样了，没有其它的目的，仅用于数据的存储而已，只不过它存储的是简单的数据。所以假如你的项目中对象都特别简洁，那么不用Model而直接传递多个参数也能做成三层架构。那为什么还要有MOdeI呢,它的好处是什么呢。下面是思索一个问题时想到的,插在这里：Model在各层参数传递时究竟能起到做大的作用？在各层间传递参数时，可以这样：AddUser(userid,UserNameUSerPaSSWord,，)也可以这样：AddUser(userinfo)这两种方法那个好呢。一目了然，确定是其次种要好很多。什么
19、时候用一般变量类型(int,string,guid.double)在各层之间传递参数，什么使用Model传递？下面几个方法：SelectUser(intUserId)SelectUserByName(stringusername)SelectUserByName(stringusernamestringpassword)SelectUserByEmail(stringemail)SelectUserByEmail(stringemailstringpassword)可以概括为：SelectUser(userid)SelectUser(user)这里用USer这个Model对象囊括了userna
20、me,password,email这三个参数的四种组合模式。USerId其实也可以合并到USer中，但项目中其它BLL都实现了带有id参数的接口，所以这里也保留这一项。传入了USerInf0,那如何处理呢，这个就需要依据先后的挨次了，有具体代码打算。这里按这个挨次处理首先看是否同时具有username和password,然后看是否同时具有email和password,然后看是否有USername,然后看是否有email。依次处理。这样，假如以后增加一个新内容，会员卡(number),则无需更改接口，只要在DAL的代码中增加对number的支持就行，然后前台增加会员卡一项内容的表现与处理即可。4
21、、UserDAL.espublicIListSelectUsersO：返回全部的用户信息列表publicUserInfoSelectUser（intUserid）：返回指定用户的信任信息publicbllnseriUser（UserInfoUser）：新增用户信息publicboolUpdaieUseKUserInfoUser）：更新用户信息publicvoidDeleleUser（inlUserid）：移除用户信息很多人最闹不清的就是数据访问层，究竟那部分才算数据访问层呢？有些认为数据库就是数据访问层，这是对定义没有搞清晰，DAL是数据访问层而不是数据存储层，因此数据库不行能是这一层的。也有
22、的把SQLHelPer（或其同类作用的组件）作为数据访问层，它又是一个可有可无的东西，SQLHeIPer的作用是削减重复性编码，提高编码效率，因此假如我习惯在乎效率或使用一个非数据库的数据源时，可以丢弃SQLHelPer,一个可以随便弃置的部分，又怎么能成为三层架构中的一层呢。可以这样定义：与数据源操作有关的代码，就应当放在数据访问层中，属于数据访问层5、IUserDAL数据访问层接口，这又是一个可有可无的东西，由于Peishop中带了它和ClassFactory类工厂，所以有些项目不论需不需要支持多数据源，都把这两个东西做了进来，有的甚至不建CIaSSFaCIory而只建了IDAL,然后IU
23、serDALiUserDal=newUserDALO;,不知意义何在。这就完全是画虎不成反类犬了。很多人在这里有一个误会，那就是以为存在这样的关系：BLLBaIDALBaDAL,认为IDAL起到了BLL和DAL之间的桥梁作用，BLL是通过IDAL来调用DAL的。但实际是即使你如此编码：4lIUserDALiUserDal=ClassFacotry-CreateUserDALO；”,那么在执行“iUserDal.SelectUsers。”时，其实还是执行的USerDAL实例，而不是IUSerDAL实例，所以IDAL在三层中的位置是与DAL平级的关系。通过上面的介绍，基本上将三层架构的层次结构说明
24、白。其实，本人有一个推断三层架构是否标准的方法，那就是将三层中的任意一层完全替换，都不会对其它两层造成影响，这样的构造基本就符合三层标准了（虽然实现起来比较难A_A）。例如假如将项目从B/S改为C/S（或相反），那么除了Ul以外，BLL与DAL都不用改动；或者将SQLSerVer改为OraCle,只需替换SQLSerVerDAL到OraCleDAL,无需其它操作等等。原来想在文中加入一些具体的代码的，但感觉不是很必要，假如大家觉得需要的话，我再补充吧。总结：不要由于某个层对你来说没用，或者实现起来特殊简洁，就认为它没有必要，或者摒弃它，或者挪作它用。只要进行了分层，不管是几层，每一层都要有明确
25、的目的和功能实现，而不要被实际过程所左右，造成同一类文件位于不同层的状况发生。也不要消失同一层实现了不同的功能的状况发生。资料三三层结构是“外观层”、“商业规律层”、“数据库层”假设以这样的结构制作一个留言板，那么应当是：#留言板页面的外观代码都存放在.aspx文件中#当用户点击页面上的提交按钮时，先将文本信息传递给一个LeaVeWOrd类对象(LeaveWord类的定义被封装到“商业规律层)#之后让这个对象执行PostO将留言信息发送到数据库用一个简洁的代码就是：/在外观层，当用户点击发送按钮后/privatevoidPosjServerClick(ObjeCtsender,EventArg
26、se)1.eaveWordlword=newLeaveWord();Iword.Content=Content-VaIue;lword.Post();1/在商业规律层，定义LeaVeWOrd类/publicclassLeaveWordpublicstringContent;publicvoidPost()(newLWordData().Post(this.Content);)1/数据库层，定义发送方法/publicclassLWordDatapublicvoidPost(stringcontent)/打开数据库，将Conten【插入到表中这样，外观层就不必费心数据库操作了理解基本正确.但是数据
27、层已经只是数据库的操作,不应当和业务有任何关系,你可以参考SqIHelperxs提示一点,系统的“层”是对代码的一种规律划分,并不是肯定要三层,假设你的系统很简洁,就一个页面,那一层就可以,假如系统很简单,也可能是n层.差不离了，核心就是外层确定不会涉及任何数据处理，他的任务是设置界面，猎取数据，输出数据业务层最重要，全部数据处理在这里，如何运用外层供应的数据处理业务数据库层一般都建议调用存储过程，返回数据集或其他所需数据;.net的那两个例子很好，多学习一下.一个原则：上层调下层上层对下层是不行见的设计时，表现层只调用规律层，表现层主要是取得页面的数据传到规律层，和把从规律层得到的数据显示到
28、页面上。规律层负责把数据加工整理传到数据层和把从数据层取得的数据加工数据层就只负责把数据对数据库操作业务规律层就是给上层和下层下达命令和调整行为的中间层资料四：基于组件的三层B/S结构概述在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推举的分层式结构一般分为三层，从下至上分别为：数据访问层、业务规律层（又或成为领域层）、表示层。三层结构原理3个层次中，系统主要功能和业务规律都在业务规律层进行处理。所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简洁地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是
29、三层体系结构,三层是指规律上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规章、数据访问、合法性校验等工作放到了中间层进行处理。通常状况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。表示层位于最外层(最上层)，离用户最近。用于显示数据和接收用户输入的数据，为用户供应一种交互式操作的界面业务规律层业务规律层(BUSineSSLogicLayer)无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规章的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域(Domain)规律有关，很多
30、时候，也将业务规律层称为领域层。例如MartinFoWler在PatternsofEnterpriseApplicationArchitecture一书中，将整个架构分为三个主要的层：表示层、领域层和数据源层。作为领域驱动设计的先驱EriCEvans,对业务规律层作了更细致地划分，细分为应用层与领域层，通过分层进一步将领域规律与领域规律的解决方案分别。业务规律层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依靠是向下的，底层对于上层而言是“无知”的，转变上层的设计对于其调用的底层而言没有任何影响。假如在分层设计时，遵
31、循了面对接口设计的思想，那么这种向下的依靠也应当是一种弱依靠关系。因而在不转变接口定义的前提下，抱负的分层式架构，应当是一个支持可抽取、可替换的“抽屉”式架构。正由于如此，业务规律层的设计对于一个支持可扩展的架构尤为关键，由于它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依靠与被依靠的关系都纠结在业务规律层上，如何实现依靠关系的解耦，则是除了实现业务规律之外留给设计师的任务。数据层数据访问层：有时候也称为是长久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。简洁的说法就是实现对数据表的SeleCl,Inserl,UPdate,Delele的操作。假如要加入ORM的元素，那么就会包括对象和数据表之间的InaPPing,以及对象实体的长久化。
