对于三层架构的认识整理
2016-03-04 11:19
337 查看
架构(三层架构)、框架(MVC)、设计模式三者异同点
软件架构 (softwarearchitecture)
软件的架构是系统的一个草图、阐述了各个组件之间的通讯、划分层次、一旦系统开始详细设计、架构蓝图就很难甚至无法更改、是由软件架构师从无到有设计出来的。
例: 三层架构:一种设计软件架构的思想
把软件上从逻辑上分为、表示层(UI)业务逻辑层(BLL)数据访问层(DAL)
目的:低耦合、高内聚、各司其职、达到易更换、修改、可以分散部署、编码。
软件框架(Softwareframework)
软件框架是在一定领域内、别人已经对这个领域制作软件所需的基础架构功能、进行了总结、做出了有代码实体的软件框架结构、如果要制作这一领域的软件、可以在别人写好的框架上、继续设计、编写自己的软件、骨头架上填肉、框架有一定的局限性。
例:MVC(框架)
英文 ModelView Controller、是针对Web开发、已经写好有代码的框架、分别为M 模型(model)-V视图(view)-C控制器(controller)三部分
目的:模型和视图分离开、使得一个模型可被多个视图使用、简单说就是同样的一个网站、用手机的视图(界面)和电脑的视图、可以共用一个模型。
设计模式(Designpattern)
对软件设计中普遍存在(反复出现)的各种问题,所提出的解决方案、是一种解决方案的思想、不拘泥于代码、通常以类型或对象来描述其中的关系和相互作用、依赖与抽象、来达到解耦和、可宽展、易维护等、设计模式是用来解决问题的。
三者区别
软件架构是指软件架构师在制作软件的时候、对软件规划的一种蓝图、一般是分层、画出各个组件的关系。
软件框架是指在特定的领域内、已经有人写好的框架(有代码)、框架有局限性、只限特定领域。
设计模式是指针对一些编程实际的问题所提出的抽象解决方案、用类与类之间的关系相互作用、达到目的。
三层架构与MVC的区别
根本区别是三成是机构而MVC是框架、MVC是应用与Web别人已经写好的代码、如ASP.NET就可以直接点击MVC、会自动生成框架代码、而三层是做软件自己划分的、是一种制作软件的思想。
三层架构并不是MVC,MVC是一个很早就有的经典的程序设计模式,M-V-C分为三层,M(Model)-V(View)-C(Control)。而web开发中的三层架构是指:数据访问层(DAL-DatabaseAccessLayer),业务逻辑层(BLL-BusinessLoginLayer),以及用户界面层(UI-UserInterface,实际就是网页后台的具体调用BLL层)。这个是基本概念。曾经我以为三层架构就是在AppCode中,分为三个大类与若干小类,各司其职。在经过一番洗礼后,才发觉多么的无知。
首先AppCode中,放的是通用类,如数据库通用类,实现数据库连接,基本的SqlCommand创建,自定义CRUD的方法等,与三层架构毫无关系,就是常用的开发模式中存放类(Class)的文件夹。
其次,当使用三层架构时,一定是在大项目中,因为三层架构的目的是提高项目的松散性和降低项目的耦合度,使之更容易扩展或者维护。小项目使用了三层架构,由于过度的在意分层而导致了项目的复杂度增加。
创建三层架构的应用程序。我们必须对这三层分别创建不同的类库(ClassLibrary),而不是普通的类(Class)。我们对于任何一个模块或者功能进行OOP,把它扩展为对象(面向对象的思想就是:将所操作的目标当成一个对象,对它进行的操作,将由对象自己的方法进行,而非外界传参。譬如注册用户,用面向过程的方法事先,就是:public static bool Register(string userName, string
userPwd)。若用OO的思想,我们不可将账号密码作为参数传入,而是将用户作为一个对象,这个对象具有private _userName,和private _userPwd的属性。在注册时,用构造函数初始化一个新的对象,User one = new User(userName,userPwd),使之在初始化后具有这两个字段的值。然后调用User类中的public static bool Register()方法(注意这个方法是不进行传参的),而在这个Register方法中,使用对象的_userName和_userPwd属性进行注册。),那么,我们在这个对象中的任何操作都将以该对象的方法(函数)实现。
在进行三层分类时,这样新建类库。
1.文件->新建项目->其他项目类型->空白解决方案。
2.在右侧的“资源管理器”中,选中当前解决方案,右键添加->新建项目->类库(ClassLibrary),分别创建BLL,DAL,UL类库。(若添加后看不到解决方案则在菜单->工具->选项->项目和解决方案->总是显示解决方案)。
3.右键,向解决方案中添加一个网站(新网站或者现有网站)。
4.根据需求删除或者保留默认添加项(默认的class1.cs或Default.aspx文件)。
这样一个三层架构的网站雏形就搭建好了。因为UI层要被其他两层引用,DAL层要被BLL层引用。所以需要相互添加引用,方法是在类库上点击右键->添加引用->项目->选择其他类库。并且在具体类中引入命名空间(using namespace)。
ps:类库其实就是类的集合,三层架构的目的就是,将同一项目的不同模块都划分为各自的三层,各司其职,将具体实现方法用类写出,添加到该层的类库中,这样,一个网站下的类库就只有三层,每一层中都包含了各个模块相对应层的实现方法。在以后修改或扩展时,在对应层中进行操作就可以了。
一般的项目,涉及最多的就是对数据库的CRUD,DAL层只负责与数据库的交互,BLL层是最重要的一层,他负责将DAL层的的结果呈现给UI层,但是恰恰BLL层的存在似乎有点鸡肋,他起到的仅仅是转发DAL层数据的作用,而具体的逻辑操作是与数据库的交互,应该写在DAL层,这就好像BLL层是在重复DAL层的劳动一样,其实BLL层的作用在于除了调用DAL层访问数据库,还可以进行逻辑判断,当符合的时候,才进行允许进行DAL的操作,或者进行额外的操作(如加密,转换等)。而DAL层可不管这些,他只管进行CRUD的动作。UI层就是操作抽象出来的实体对象,它包含了各种属性。
一个三层架构的小例子:注册新用户。
先写模块的实体类,是数据库中表的抽象,假设数据库中注册信息只有账号,密码两个字段。那么抽象到实体类就是这样:
再写DAL层:
再写BLL层:
最后构建UI层代码,即我们的aspx.cs页面代码,该层应该直接调用BLL层的方法。该页面引用BLL和Entity的命名空间,并向Button控件注册事件:
这样一个小的三层架构程序就出来了。
这个程序中,操作的实体为UserInfo表的抽象。在DAL层进行了AddUser()的方法,在BLL层也进行了AddUser()的方法,唯一的区别是BLL层做了逻辑判断,如果用户名存在,则注册失败。
三层架构的特点:
1.数据库访问层(DAL)仅提供对数据库的CRUD(增删改查)操作,而不管操作后的结果,也不管逻辑过程(譬如同名用户,不合法用户名)。
2.业务逻辑层(BLL)不会直接与数据库交互,他与数据库的交互是通过DAL提供的方法。在调用这些方法前,要加入自己的逻辑判断或者业务处理。另外业务逻辑层(BLL)还有可能不会去调用DAL层的方法,而是进行其他业务处理。
3.用户界面层(UI)层是不会调用DAL层的,他只调用BLL层提供的方法,再由BLL层自己决定是否继续调用DAL层。
这个例子可以看出三层架构的优点就是结构清晰,容易扩展与维护。缺点就是,复杂,。“三层结构”开发模式,不适用于对执行速度要求过于苛刻的系统。仅仅一个注册用户,就这么麻烦,所以对于小项目来说,费这么大劲换取一个相对较清晰的分层结构是不划算的。
从开发角度上分析,开发人员可以将应用的商业逻辑放在中间层应用服务器上,把应用的业务逻辑与用户界面分开。在保证客户端功能的前提下,为用户提供一个简洁的界面。这意味着如果需要修改应用程序代码,只需要对中间层应用服务器进行修改,而不用修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发,简化了应用系统的开发、更新和升级工作。
理解ASP.NET中的三层结构——为什么要分三层?我们用三层结构主要是使项目结构更清楚,分工更明确,有利于后期的维护和升级。它未必会提升性能,因为当子程序模块未执行结束时,主程序模块只能处于等待状态。这说明将应用程序划分层次,会带来其执行速度上的一些损失。但从团队开发效率角度上来讲却可以感受到大不相同的效果。需要说明一下,三层结构不是.NET的专利,也不是专门用在数据库上的技术。它是一种更加普适的架构设计理念。
如何建立一个三层体系结构解决方案
RL层是逻辑判断层,主要是对页面上传入的数据进行逻辑判断。
RL层之上就是UI如何建立一个三层体系结构解决方案新建一个空白解决方案。然后:
“添加”-“新建项目”-“其他项目”-“企业级模版项目”-“C#生成块”-“数据访问”(数据层,下简称D层)
“添加”-“新建项目”-“其他项目”-“企业级模版项目”-“C#生成块”-“业务规则”(业务层,下简称C层)
“添加”-“新建项目”-“其他项目”-“企业级模版项目”-“C#生成块”-“Web用户界面”(界面层,下简称U层)
右键点“解决方案”-“项目依赖项”,设置U依赖于D、C,C依赖于D。
对U添加引用D、C,对C添加引用D。
到此为止,一个三层的架子建立起来了。
特点
“三层结构”开发模式,入门难度够高,难于理解和学习。这是对于初学程序设计的人来说的。以这种模式开发出来的软件,代码量通常要稍稍多一些。这往往会令初学者淹没在茫茫的代码之中。望之生畏,对其产生反感,也是可以理解的……
其实,无论哪一种开发模式或方法,都是有利有弊的。不会存在一种“万用法”可以解决任何问题。所以“三层结构”这个词眼也不会是个例外!是否采用这个模式进行系统开发,要作出比较、权衡之后才可以。切忌滥用!
参与资料
MainDoc.rar (《浅谈“三层结构”原理与用意》1.30M)
http://www.bincess.cn/Downloads/MainDoc.rar
petshop 4.0的体系结构(只是稍微看了一下,了解一下结构)
简介:PetShop随着版本的不断更新,至现在基于.Net 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,而且有很多可以借鉴之处。PetShop是一个小型的项目,系统架构与代码都比较简单,却也凸现了许多颇有价值的设计与开发理念。
下载地址:http://msdn.microsoft.com/en-us/library/aa479070.aspx
PetShop架构设计
三层”应用结构:数据访问层、业务逻辑层(领域层)、表示层
分层的设计的特点:
结构清晰、耦合度低
便于系统的扩展
利于开发任务同步进行
降低了一定的性能
软件架构 (softwarearchitecture)
软件的架构是系统的一个草图、阐述了各个组件之间的通讯、划分层次、一旦系统开始详细设计、架构蓝图就很难甚至无法更改、是由软件架构师从无到有设计出来的。
例: 三层架构:一种设计软件架构的思想
把软件上从逻辑上分为、表示层(UI)业务逻辑层(BLL)数据访问层(DAL)
目的:低耦合、高内聚、各司其职、达到易更换、修改、可以分散部署、编码。
软件框架(Softwareframework)
软件框架是在一定领域内、别人已经对这个领域制作软件所需的基础架构功能、进行了总结、做出了有代码实体的软件框架结构、如果要制作这一领域的软件、可以在别人写好的框架上、继续设计、编写自己的软件、骨头架上填肉、框架有一定的局限性。
例:MVC(框架)
英文 ModelView Controller、是针对Web开发、已经写好有代码的框架、分别为M 模型(model)-V视图(view)-C控制器(controller)三部分
目的:模型和视图分离开、使得一个模型可被多个视图使用、简单说就是同样的一个网站、用手机的视图(界面)和电脑的视图、可以共用一个模型。
设计模式(Designpattern)
对软件设计中普遍存在(反复出现)的各种问题,所提出的解决方案、是一种解决方案的思想、不拘泥于代码、通常以类型或对象来描述其中的关系和相互作用、依赖与抽象、来达到解耦和、可宽展、易维护等、设计模式是用来解决问题的。
三者区别
软件架构是指软件架构师在制作软件的时候、对软件规划的一种蓝图、一般是分层、画出各个组件的关系。
软件框架是指在特定的领域内、已经有人写好的框架(有代码)、框架有局限性、只限特定领域。
设计模式是指针对一些编程实际的问题所提出的抽象解决方案、用类与类之间的关系相互作用、达到目的。
三层架构与MVC的区别
根本区别是三成是机构而MVC是框架、MVC是应用与Web别人已经写好的代码、如ASP.NET就可以直接点击MVC、会自动生成框架代码、而三层是做软件自己划分的、是一种制作软件的思想。
三层架构并不是MVC,MVC是一个很早就有的经典的程序设计模式,M-V-C分为三层,M(Model)-V(View)-C(Control)。而web开发中的三层架构是指:数据访问层(DAL-DatabaseAccessLayer),业务逻辑层(BLL-BusinessLoginLayer),以及用户界面层(UI-UserInterface,实际就是网页后台的具体调用BLL层)。这个是基本概念。曾经我以为三层架构就是在AppCode中,分为三个大类与若干小类,各司其职。在经过一番洗礼后,才发觉多么的无知。
首先AppCode中,放的是通用类,如数据库通用类,实现数据库连接,基本的SqlCommand创建,自定义CRUD的方法等,与三层架构毫无关系,就是常用的开发模式中存放类(Class)的文件夹。
其次,当使用三层架构时,一定是在大项目中,因为三层架构的目的是提高项目的松散性和降低项目的耦合度,使之更容易扩展或者维护。小项目使用了三层架构,由于过度的在意分层而导致了项目的复杂度增加。
创建三层架构的应用程序。我们必须对这三层分别创建不同的类库(ClassLibrary),而不是普通的类(Class)。我们对于任何一个模块或者功能进行OOP,把它扩展为对象(面向对象的思想就是:将所操作的目标当成一个对象,对它进行的操作,将由对象自己的方法进行,而非外界传参。譬如注册用户,用面向过程的方法事先,就是:public static bool Register(string userName, string
userPwd)。若用OO的思想,我们不可将账号密码作为参数传入,而是将用户作为一个对象,这个对象具有private _userName,和private _userPwd的属性。在注册时,用构造函数初始化一个新的对象,User one = new User(userName,userPwd),使之在初始化后具有这两个字段的值。然后调用User类中的public static bool Register()方法(注意这个方法是不进行传参的),而在这个Register方法中,使用对象的_userName和_userPwd属性进行注册。),那么,我们在这个对象中的任何操作都将以该对象的方法(函数)实现。
在进行三层分类时,这样新建类库。
1.文件->新建项目->其他项目类型->空白解决方案。
2.在右侧的“资源管理器”中,选中当前解决方案,右键添加->新建项目->类库(ClassLibrary),分别创建BLL,DAL,UL类库。(若添加后看不到解决方案则在菜单->工具->选项->项目和解决方案->总是显示解决方案)。
3.右键,向解决方案中添加一个网站(新网站或者现有网站)。
4.根据需求删除或者保留默认添加项(默认的class1.cs或Default.aspx文件)。
这样一个三层架构的网站雏形就搭建好了。因为UI层要被其他两层引用,DAL层要被BLL层引用。所以需要相互添加引用,方法是在类库上点击右键->添加引用->项目->选择其他类库。并且在具体类中引入命名空间(using namespace)。
ps:类库其实就是类的集合,三层架构的目的就是,将同一项目的不同模块都划分为各自的三层,各司其职,将具体实现方法用类写出,添加到该层的类库中,这样,一个网站下的类库就只有三层,每一层中都包含了各个模块相对应层的实现方法。在以后修改或扩展时,在对应层中进行操作就可以了。
一般的项目,涉及最多的就是对数据库的CRUD,DAL层只负责与数据库的交互,BLL层是最重要的一层,他负责将DAL层的的结果呈现给UI层,但是恰恰BLL层的存在似乎有点鸡肋,他起到的仅仅是转发DAL层数据的作用,而具体的逻辑操作是与数据库的交互,应该写在DAL层,这就好像BLL层是在重复DAL层的劳动一样,其实BLL层的作用在于除了调用DAL层访问数据库,还可以进行逻辑判断,当符合的时候,才进行允许进行DAL的操作,或者进行额外的操作(如加密,转换等)。而DAL层可不管这些,他只管进行CRUD的动作。UI层就是操作抽象出来的实体对象,它包含了各种属性。
一个三层架构的小例子:注册新用户。
先写模块的实体类,是数据库中表的抽象,假设数据库中注册信息只有账号,密码两个字段。那么抽象到实体类就是这样:
using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Entity { class UserInfo { public string UserName { get; set; } //C#3.0中属性构造器的新写法; public string UserPwd { get; set; } } }
再写DAL层:
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Data; using System.Data.SqlClient; using Entity; //这里添加对Entity实体类的引用; namespace DAL { public class UserDAL { //在该类中,为了方便,一般会构造一个DataBaseFactory,方便进行代码的操作。所以以下代码仅为逻辑实现,不代表代码正确。 public bool AddUser(UserInfo uInfo) //这里将实体类作为参数传入; { string sqlStr="INSERT INTO UserInfo(Name,Pwd) VALUES(@name,@pwd)"; SqlCommand cmd=new SqlCommand(sqlStr); cmd.Parameters.Clear(); cmd.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = uInfo.UserName; //调用实体类的属性 cmd.Parameters.Add("@pwd", SqlDbType.NVarChar, 50).Value = uInfo.UserPwd; return Convert.ToInt32(cmd.ExecuteNonQuery()) > 0 ? true : false; } public DataTable GetUserInfo(string name) //根据用户名获得用户的具体信息 { string sqlStr="SELECT * FROM UserInfo WHERE Name=@name"; SqlCommand cmd=new SqlCommand(sqlStr); cmd.Parameters.Clear(); cmd.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = name; SqlDataAdapter sda = new SqlDataAdapter(cmd); DataSet ds=new DataSet(); sda.Fill(ds,"UserInfo"); return ds.Tables["UserInfo"]; } } }
再写BLL层:
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Data; using Entity; //添加对Entity类库的引用 using DAL; //添加对DAL类库的引用 namespace BLL { public class UserBLL { public static bool AddUser(UserInfo uInfo) //BLL层的方法多为静态方法,DAL层也可以为静态方法。 { UserDAL uDal = new UserDAL(); DataTable dTable = uDal.GetUserInfo(uInfo.UserName); if (dTable.Rows.Count > 0) //这里对注册用户有一个判断,从DAL层中先通过注册名获得用户的具体信息,若可以获得则证明该用户名已被注册,返回false; return false; else return uDal.AddUser(uInfo); } } }
最后构建UI层代码,即我们的aspx.cs页面代码,该层应该直接调用BLL层的方法。该页面引用BLL和Entity的命名空间,并向Button控件注册事件:
protected void btnRegister_OnClick(object sender, EventArgs e) { UserInfo uInfo = new UserInfo(textUserName.text, textUserPwd.text); if (UserBLL.AddUser(uInfo)) Response.Write("注册成功!"); else Response.Write("注册失败!"); }
这样一个小的三层架构程序就出来了。
这个程序中,操作的实体为UserInfo表的抽象。在DAL层进行了AddUser()的方法,在BLL层也进行了AddUser()的方法,唯一的区别是BLL层做了逻辑判断,如果用户名存在,则注册失败。
三层架构的特点:
1.数据库访问层(DAL)仅提供对数据库的CRUD(增删改查)操作,而不管操作后的结果,也不管逻辑过程(譬如同名用户,不合法用户名)。
2.业务逻辑层(BLL)不会直接与数据库交互,他与数据库的交互是通过DAL提供的方法。在调用这些方法前,要加入自己的逻辑判断或者业务处理。另外业务逻辑层(BLL)还有可能不会去调用DAL层的方法,而是进行其他业务处理。
3.用户界面层(UI)层是不会调用DAL层的,他只调用BLL层提供的方法,再由BLL层自己决定是否继续调用DAL层。
这个例子可以看出三层架构的优点就是结构清晰,容易扩展与维护。缺点就是,复杂,。“三层结构”开发模式,不适用于对执行速度要求过于苛刻的系统。仅仅一个注册用户,就这么麻烦,所以对于小项目来说,费这么大劲换取一个相对较清晰的分层结构是不划算的。
从开发角度上分析,开发人员可以将应用的商业逻辑放在中间层应用服务器上,把应用的业务逻辑与用户界面分开。在保证客户端功能的前提下,为用户提供一个简洁的界面。这意味着如果需要修改应用程序代码,只需要对中间层应用服务器进行修改,而不用修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发,简化了应用系统的开发、更新和升级工作。
理解ASP.NET中的三层结构——为什么要分三层?我们用三层结构主要是使项目结构更清楚,分工更明确,有利于后期的维护和升级。它未必会提升性能,因为当子程序模块未执行结束时,主程序模块只能处于等待状态。这说明将应用程序划分层次,会带来其执行速度上的一些损失。但从团队开发效率角度上来讲却可以感受到大不相同的效果。需要说明一下,三层结构不是.NET的专利,也不是专门用在数据库上的技术。它是一种更加普适的架构设计理念。
如何建立一个三层体系结构解决方案
RL层是逻辑判断层,主要是对页面上传入的数据进行逻辑判断。
RL层之上就是UI如何建立一个三层体系结构解决方案新建一个空白解决方案。然后:
“添加”-“新建项目”-“其他项目”-“企业级模版项目”-“C#生成块”-“数据访问”(数据层,下简称D层)
“添加”-“新建项目”-“其他项目”-“企业级模版项目”-“C#生成块”-“业务规则”(业务层,下简称C层)
“添加”-“新建项目”-“其他项目”-“企业级模版项目”-“C#生成块”-“Web用户界面”(界面层,下简称U层)
右键点“解决方案”-“项目依赖项”,设置U依赖于D、C,C依赖于D。
对U添加引用D、C,对C添加引用D。
到此为止,一个三层的架子建立起来了。
特点
“三层结构”开发模式,入门难度够高,难于理解和学习。这是对于初学程序设计的人来说的。以这种模式开发出来的软件,代码量通常要稍稍多一些。这往往会令初学者淹没在茫茫的代码之中。望之生畏,对其产生反感,也是可以理解的……
其实,无论哪一种开发模式或方法,都是有利有弊的。不会存在一种“万用法”可以解决任何问题。所以“三层结构”这个词眼也不会是个例外!是否采用这个模式进行系统开发,要作出比较、权衡之后才可以。切忌滥用!
参与资料
MainDoc.rar (《浅谈“三层结构”原理与用意》1.30M)
http://www.bincess.cn/Downloads/MainDoc.rar
petshop 4.0的体系结构(只是稍微看了一下,了解一下结构)
简介:PetShop随着版本的不断更新,至现在基于.Net 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,而且有很多可以借鉴之处。PetShop是一个小型的项目,系统架构与代码都比较简单,却也凸现了许多颇有价值的设计与开发理念。
下载地址:http://msdn.microsoft.com/en-us/library/aa479070.aspx
PetShop架构设计
三层”应用结构:数据访问层、业务逻辑层(领域层)、表示层
分层的设计的特点:
结构清晰、耦合度低
便于系统的扩展
利于开发任务同步进行
降低了一定的性能
相关文章推荐
- iOS 分层架构设计
- 1.常见的三种存储架构(DAS、NAS、SAN)
- 在我的lnmp环境上部署我的网站
- 从Hadoop到Spark的架构实践
- 负载均衡—大型网站架构系列:负载均衡详解(上)
- xampp下创建多个虚拟网站目录
- 如何让网站判断是手机客户端访问,如果是跳到手机版
- Solaris10 sparc架构下安装gdb和简单调试
- 理解RESTful架构(转)
- 《架构师成长之路》连载之NO.2
- 大型网站电商网站架构案例和技术架构的示例
- 大型网站架构不得不考虑的 10 个问题
- 浅谈Web网站架构演变过程及各阶段所用的技术和架构设计
- 让你的HTML5&CSS3网站在老IE中也能…
- Android应用开发架构
- 网站大流量解决
- 利用phpStudy 探针 提权网站服务器
- JAVA网站高并发解决方案
- Android学习网站,资料推荐,学习经验共享
- 提高PHP网站性能的经验总结