基于.NET平台的分层架构实战.doc

基于.NET平台的分层架构实战(完整资料）(可以直接使用，可编辑 优秀版资料，欢迎下载） 通过浏览博客园的文章发现，很多朋友对分层架构特别感兴趣，刚好我刚做完的毕业设计就是专门研究NT平台上分层架构的（题目叫“基于.NET平台的分层架构与设计模式应用研究”）.通过做这篇论文,我对分层架构有了一定的了解，所以，就萌发了想写一个文章系列，详述一下分层架构。然而，论文的理论性太强，不适合在网上发布,尤其不适合初学者理解，所以，我想在这个文章系列中,少讲理论，而是通过做一个完整的案例来讨论分层架构的基本方法，这样会直观很多。希望在这个文章系列的写作过程中，能和朋友们一起学习,一起进步。 为了让朋友们把主要精力放在理解分层架构而不是案例本身，我准备选择一个相对简单的留言本系统作为Deo,这个系统的名字就叫做NGuestBok。 初步计划将这个文章系列分为以下几篇： 综述 .系统需求分析及数据库设计 3架构概要设计 .实体类的实现 。接口的设计与实现 6。依赖注入及Io的设计与实现 。数据访问层的第一种实现ccess+动态生成QL语言 8.数据访问层的第二种实现SQLSve+存储过程9.数据访问层的第三种实现基于NBea框架的ORM实现 10业务逻辑层的实现1。表示层的实现 1。使用SP.NET JAX框架对表示层进行改进 13.总结 当然,以上只是初步计划，在写文章的过程中可能会根据具体情况适当调整,但是内容大体就是这些。 这个文章系列不会对所用到的技术进行详细讲解，具体请参考相关文献，阅读文章前最好能对以下技术有一个了解： 1.语言 2。ASNET .设计模式 .关系数据库基础知识 软件架构基本原则与软件工程基础知识 。基于NBear框架的OR技术7。vcript，Ajax 。AP.NET AJAX框架（特别是客户端编程）HTML，SS,标准化布局 另外,本文章系列是基于.NE fraewo2.0框架平台进行讨论，。5平台的新特性(如INQ、ASP.NTM等)不会讨论,I使用Visual Stud005,数据库会用到SQLSver205 Eprss和Accss2003。 在实际的项目中,需求分析和数据库的设计是很重要的一个环节，这个环节会直接影响项目的开发过程和质量。实际中，这个环节不但需要系统分析师、软件工程师等计算机方面的专家,还需要相关领域的领域专家参与才能完成。 但是，在这个文章系列中,所要使用的De仅仅是一个例子，而且其业务极为简单,因此,这里并不是真正的需求分析和数据库设计，而是将Deo的需求和数据库罗列至此，使朋友们对Demo有一个大体的了解，方便后续文章中开发过程的理解。需求分析: 这个项目是一个留言本,其业务极为简单，现将其描述如下。任何访问者可以进行留言,留言完成后，不会立即显示正文,而是要经过管理员验证后才可显示。 2。任何访问者可以对留言发表评论,未通过验证的留言不可以评论。 3.管理员可以对留言进行回复（这个回复不同于评论，是直接显示在正文下面,而且是一个留言只能有一个回复），并可对留言与评论实行删除，以及对留言进行通过验证操作。.管理员分为超级管理员和普通管理员。超级管理员只有一个，负责对普通管理员实行添加、删除操作.普通管理员可偶多个，负责对留言的管理，并可以修改自己的登录密码. 这个项目的用例图如下:数据库设计： 设计数据表之前，首先进行实体和关系的识别与确定。 通过需求分析，可以观察得出,本项目的实体有:管理员(不包括超级管理员），留言,评论。本项目的关系有：留言与评论间的一对多关系.进一步，数据库各表的设计如下: 管理员表（Admin） I int管理员ID NtNll 主键，自增 Namarhr（0)登录名 NotNullPswodvrhar(50) 登录密码NotNull 使用D5加密留言表（Tsage） ID int 留言ID NotNull 主键,自增GuestName varcr（20）留言者用户名 NotN GustEmil varchar(100)留言者-ail NllCntent text 留言内容NotNlT attie 发表留言时间NotNll Repytext 回复 Null sPassvahar（1） 是否通过验证 otNull 评论表(TComn） ontn txt 评论内容 NotlTimeatetim 发表评论时间 NotNll essageID int 所属留言的ID外键 基于。NET平台的分层架构实战（三）架构概要设计本文主要是对将要实现的架构进行一个总体的描述,使朋友们对这个架构有个宏观上的认识。这篇文章理论性的东西会偏多一点，从下篇开始,将进行实际项目的开发.这篇文章的许多内容摘自我的毕业论文.架构基本原则：这里，将描述一些在这个架构设计中的基本原则，其中很多都是经典的设计原则,不过针对分层架构的特点,用我自己的语言进行了描述。其中也有我自己提出的原则。逐层调用原则及单向调用原则现在约定将N层架构的各层依次编号为1、2、N1、N，其中层的编号越大，则越处在上层.那么，我们设计的架构应该满足以下两个原则：1.第K(12.如果P层依赖Q层，则P的编号一定大于Q。其中第一个原则,保证了依赖的逐层性,及整个架构的依赖是逐层向下的,而不能跨层依赖。第二个原则，则保证了依赖的单向性,及只能上层依赖底层,而不能底层反过来依赖上层。针对接口编程，而不是针对实现编程这里所指的接口,不是特指编程语言中的具体语言元素(如#中由Ineace定义的语言接口），而是指一种抽象的，在语义层面上起着接合作用语义体。它的具体实现,可能是接口，可能是抽象类，甚至可能是具体类。我认为，从不同的视角,接口可以有以下两种定义：接口是一组规则的集合，它规定了实现本接口的类或接口必须拥有的一组规则。体现了自然界“如果你是则必须能”的理念。2。接口是在一定粒度视图上同类事物的抽象表示。注意这里我强调了在一定粒度视图上，因为“同类事物”这个概念是相对的,它因为粒度视图不同而不同。具体到N层架构中，针对接口编程的意义在部分上是这样的：现仍约定将层架构的各层依次编号为1、2、K、N-1、N，其中层的编号越大,则越处在上层，那么第K层不应该依赖具体一个K-层，而应该依赖一个K层的接口,即在第K层中不应该有K1层中的某个具体类.依赖倒置原则在软件设计原则中，有一种重要的思想叫做依赖倒置。它的核心思想是：不能让高层组件依赖底层组件,而且,不管高层组件和底层组件,两者都应依赖于抽象。那么,这个原则和我们上面的原则是否矛盾呢?其实并不矛盾。因为这个原则定义中的“依赖”是指“具体依赖，而上面定义中的依赖全部指“抽象依赖”。我对这两种依赖的定义如下：具体依赖如果P层中有一个或一个以上的地方实例化了Q层中某个具体类,则说P层具体依赖于层。抽象依赖-如果层没有实例化Q层中的具体类，而是在一个或一个以上的地方实例化了Q层中某个接口，则说P层抽象依赖于层，也叫接口依赖于Q层。从这两个定义可以看到,所谓的依赖倒置原则,正是上面提到针对接口编程，而不是针对实现编程,两者在本质上是统一的.综上所述,可以看出，本课题设计的分层架构,应该是这样一种架构:。层架构的各层依次编号为、2、K、N1、N，其中层的编号越大,则越处在上层。2.架构中仅存在一种依赖，即第K层接口依赖第K1层，其中1封装变化原则封装变化的原则定义为：找出应用中可能需要变化之处，把它们独立出来,不要和那些不需要变化的代码混杂在一起。开放关闭原则开发-关闭原则定义为：对扩展开放,对修改关闭.具体到层架构中，可以描述为:当某一层有了一个新的具体实现时,它应该可以在不修改其他层的情况下，与此新实现无缝连接，顺利交互。单一归属原则在这个架构中，任何一个操作类都应该有单一的职责，属于单独的一层,而不能同时担负两种职责或属于多个层次（实体类及辅助类可以被多个层使用，但它们不属于任何一个层，而是独立存在)。层次划分：目前，典型的分层架构是三层架构,即自底向上依次是数据访问层、业务逻辑层和表示层.这种经典架构经历了时间的考验和实践的多次检验,被认为是合理、有效的分层设计，所以，在本文中，将沿袭这种经典架构，使用数据访问层、业务逻辑层和表示层的三层架构体系.职责划分：目前，在典型的三层架构中,对层次各自的职责划分并没有一个统一的规范，综合现有的成功实践和.NET平台的特殊性,在本文中将三层架构的职责划分如下：数据访问层-负责与数据源的交互，即数据的插入、删除、修改以及从数据库中读出数据等操作。对数据的正确性和有效性不负责,对数据的用途不了解，不负担任何业务逻辑。业务逻辑层-负责系统领域业务的处理，负责逻辑性数据的生成、处理及转换。对流入的逻辑性数据的正确性及有效性负责，对流出的逻辑性数据及用户性数据不负责，对数据的呈现样式不负责。表示层-负责接收用户的输入、将输出呈现给用户以及访问安全性验证。对流入的数据的正确性和有效性负责,对呈现样式负责，对流出的数据正确性不负责,但负责在数据不正确时给出相应的异常信息。模块划分及交互设计：综合以上分析,可在宏观上将整个系统分为一下几个模块：实体类模块-一组实体类的集合，负责整个系统中数据的封装及传递。数据访问层接口族一组接口的集合，表示数据访问层的接口。业务逻辑层接口族-一组接口的集合，表示业务逻辑层的接口。数据访问层模块一组类的集合,完成数据访问层的具体功能，实现数据访问层接口族。业务逻辑层模块一组类的集合，完成业务逻辑层的具体功能,实现业务逻辑层接口族。表示层模块程序及可视元素的集合，负责完成表示层的具体功能。IoC容器模块负责依赖注入的实现。辅助类模块完成全局辅助性功能。各模块见交互关系如下：图1这篇中理论比较多，但是它是整个架构的基础，可以帮助朋友们对将要实现的项目架构及要遵循的原则有一个整体的了解.当然,在后续文章中，将主要讨论em项目的实际开发过程,那时,这些思想和理论性的东西将得到体现。 实体类是现实实体在计算机中的表示。它贯穿于整个架构，负担着在各层次及模块间传递数据的职责。一般来说,实体类可以分为“贫血实体类”和“充血实体类”，前者仅仅保存实体的属性，而后者还包含一些实体间的关系与逻辑.我们在这个De中用的实体类将是“贫血实体类。 大多情况下，实体类和数据库中的表（这里指实体表，不包括表示多对多对应的关系表）是一一对应的，但这并不是一个限制,在复杂的数据库设计中,有可能出现一个实体类对应多个表，或者交叉对应的情况。在本文的Demo中，实体类和表是一一对应的，并且实体类中的属性和表中的字段也是对应的。在看实体类的代码前,先看一下系统的工程结构。 如上图所示，在初始阶段，整个系统包括6个工程，它们的职责是这样的:Web-表示层ntit存放实体类 Factory存放和依赖注入及o相关的类 IL存放业务逻辑层接口族 DA-存放数据访问层接口族 Uility-存放各种工具类及辅助类这只是一个初期架构，主要是将整个系统搭一个框架,在后续开发中,将会有其他工程被陆陆续续添加进来.我们的实体类将放在Etty工程下，这里包括三个文件:minnfocs,MessgeInfo。cs，ommetIfo。c,分别是管理员实体类、留言实体类和评论实体类。具体代码如下:dmnIo。s：Adminnfo1usinSysem；2namespaNGuestBook.Entty4/*/实体类管理员7/8Seralizbe9ubicasAminno10privntid；12pivatestringnme；13rivatesrngpasswd;1415publicintID1617getreturnhisid；setthis。d=vlue；19202pblistringNam23geetnhiname；24setsnaeval；25227bicstringPassword28gteurntspasword;30settis.pasworalu;3133334Mesagnos：MessagInf1singystem；3namesaceNGuestBook。Entity5/*/smm6/实体类-留言/ummary8Seriazable9publiclassagInfo0pivaent；12ivatesinguetNme；13privtestrigesEmal;14rvatestrincone;1privteDaeTimee；6piaestrngrepl；17privatetiisa；1819publiinID2021eteturnths.i；22seth.idvalu；23225uicstringGuesae62gtreturthis.uesNme;28sttis.usName=vaue；293031publistingGuestEmal3233geturtis.guestEml；3setthis.gustEmailalue；33637pblicstringCntent839etturnhis。conent；40stthi.content=value；44243plDateTieTim4445getretuthis。tme；46etthitime=vae；47849pulistngReply5051eteturnths。reply;52seths.rely=value；555pblicstrigsPss557gteturntis.isas；58ttis.Ps=vale;5960162CometIf.cs:CommetInfousingSystem；23apaceGetBok。Ey4/*/suy6/实体类评论7/ummary8Serializable9publicclssCoetInfo111rivaeid；1pivatestrigcoent;13rivteateTimetime;14rvaetmessage;1516blicintID1718gereturnthisid；9sei.idvalue；0122publicinontet22geeturthsntet；25setthis.ontealue；27publicDteTimeme230getrtuthisme；31setthi.ti=vae；2333puicitMesae356getrturnthismesage；3setths。mssae=vaue；38391 大家可以看出,实体类的代码很简单,仅仅是负责实体的表示和数据的传递,不包含任何逻辑性内容。下篇将介绍接口的设计。 接下来，将进行接口的设计。这里包括数据访问层接口和业务逻辑层接口.在分层架构中，接口扮演着非常重要的角色，它不但直接决定了各层中的各个操作类需要实现何种操作,而且它明确了各个层次的职责。接口也是系统实现依赖注入机制不可缺少的部分。本项目的接口设计将按如下顺序进行： 1首先由前文的需求分析,列出主要的I部分. 2.分析各个I需要什么业务逻辑支持，从而确定业务逻辑层接口。 。分析业务逻辑层接口需要何种数据访问操作，从而确定数据访问层接口。 另外，为保证完全的面向对象特性，接口之间的数据传递主要靠实体类或实体类集合,禁止使用DataTale等对象传递数据。由需求分析，列出主要U 需求分析部分，请参看基于。E平台的分层架构实战（二)需求分析与数据库设计。有需求分析，可以列出系统中主要应包括以下UI: I01主页面，列出全部的留言及相应评论，支持分页显示.留言按发表时间逆序显示，评论紧跟在相应留言下.管理员可以通过相应链接对留言执行通过验证、删除、回复以及对评论进行删除操作。游客可通过相应连接进入发表留言评论页面。 UI0-发表留言页面，供游客发表新留言. UI03-发表评论页面，供游客发表评论。 UI0-回复留言页面，供管理员回复留言. I05-管理员登录页面。 U6-管理员修改个人密码的页面。 UI07超级管理员登录后的页面，主要提供管理员列表。可以通过相应链接将指定管理员删除。 UI8-添加新管理员的页面。UI0-操作成功完成后的跳转提示页面。UI10系统出现异常时显示友好出错信息的页面。由UI识别业务逻辑操作 I01：按分页取得留言，按指定留言取得全部评论,将指定留言通过验证，将指定留言删除，将指定评论删除 UI02：添加新留言 I0:添加新评论 I04:回复留言 I05：管理员登录 U06：修改管理员密码U：取得全部管理员信息,删除管理员U8:添加新管理员 经过整理,可得以下接口操作： IAdnLL:A（添加管理员)，Reve（删除管理员），CangePswor（修改管理员密码），Lon（管理员登录）,etAll（取得全部管理员） MesageBLL:dd(添加留言)，mov(删除留言），Revrt（回复留言），ass（将留言通过验证),GeByPae(按分页取得留言)IComment：Add(添加评论)，Rmove（删除评论）,Getessge（按留言取得全部评论） 这三个接口文件都放在ILL工程下,具体代码如下：IdminBL.cs：IdnBL1usigystm；2usingSystm.Clletons.ene;usnSysem.Tet；4singGetBook。Entity；5naepaGestooIBLL8/smmary9/业务逻辑层接口管理员10/summy1publicnterfIAdmBLL213/*/summary14/添加管理员15/新管理员实体类/pam17/rtrs是否成功8oolAd(dnIfamin);1920/uar1/删除管理员22/summary3/parnam=i”欲删除的管理员的ID24/是否成功/eturn2booRemve（intd）；2627/ummry/修改管理员密码9/summary/欲修改密码的管理员的I/para1/parmneassword新密码/param32/etun是否成功3ooChangeasor(intid，strngpasord）;3435*/umr3/管理员登录7/3/amnam=”name管理员登录名/paa/40/returns如果登录成功,则返回相应管理员的实体类，否则返回null/eturnsAdminInoLin(tringme,snpaswd）;443/*/ummary4/取得全部管理员信息45/summry4/return管理员实体类集合reuns7ListAdinIftAll()；849IMssageBLL.cs:MessagLL1uigSstm；usingSyem.olleios。enrc；usngSystem。ext;4usingNGek.Etity；naespacNGuesBo.IBLL78/mmay/业务逻辑层接口留言10/11blicinteraeIMessaeBL1213/*/summary14/添加留言1/summry16/pana=”ms新留言实体类para17/reun是否成功retrns8bold（MessaeInomesage）;1920/ummary21/删除留言22/ummary23/24/是否成功/returs2bolRmove(tid)；227*/summay28/回复留言9/sm3/paramname=id”要回复的留言的ID/par31/aramnae=”rely回复信息/aram32/是否成功eturns3boolvert(inid，stringreply）;335/*/summy6/将留言通过验证37/mr38/通过验证的留言的I39/rturns是否成功rurn4oolPa（in)；4142/*/sumary43/按分页取得留言信息44/ummar45/parmam=”paeze每页显示几条留言/paam46/paramn=paeNumber当前页码7/rturns留言实体类集合/reuns4IistssageInfoGeByPae(intpageSie，npageNumbe）;450ICometBLL。sIComntLL1usgSstem;2usingSyste。Colectios。Genric；3usingSystemTex;4uingGstBo.ntity;namespaceNuesok.LL78/smmary9/业务逻辑层接口-评论0/sumay11pblicineceCometBLL213/*/1/paramnme=commet”新评论实体类17/是否成功/retrnsbooldd（CometInfocommt）；1920/smmar21/删除评论22/sumry23/paamnid欲删除的评论的ID/paam24/reurns是否成功bolemve(intid）；227/*/summry28/取得指定留言的全部评论29/30/指定留言的ID评论实体类集合/retrs2IListCommentInfotyessage（insageId);33 由业务逻辑确定数据访问操作 IdmiBLL需要的数据访问操作：插入管理员，删除管理员，更新管理员信息，按D取得管理员信息，按登录名与密码取得管理员，取得全部管理员 IMesBLL需要的数据访问操作：插入留言，删除留言，更新留言信息，按D取得留言信息,按分页取得留言ComntBLL需要的数据访问操作：插入评论,删除评论,按留言取得全部评论 另外,添加管理员时需要验证是否存在同名管理员，所以需要添加一个“按登录名取得管理员”. 对以上操作进行整理,的如下接口操作：AnAL：Insert，Delet，Updat,GetByID，GetBNameAndPssword，GetAl MessageDAL：Insert,Deee，Updae，GByI，GeByPe IommtDAL:Inser，Delete，GetByssage 这三个接口文件放在DAL工程下，具体代码如下：IAdmnDAL。cs:IAdminDA1usingSyte；igSystm.Collectons。eneric；3singSyemText；usngGstB.Entit；5mespceNGuesBookIDAL78/sumar/数据访问层接口-管理员0/sumarypublcinerfacIAdmiAL121/*/4/插入管理员/sumry16/管理员实体类/parm17/return是否成功/rer18boosr(AdminIadmn）;1920/*/su21/删除管理员2/欲删除的管理员的D/aram/retur是否成功bolee（iid)；62/su