浅谈三层结构的原理与用意
- 格式:doc
- 大小:145.00 KB
- 文档页数:15
三层结构原理三层结构原理是一种用于构建复杂系统的设计方法,它将系统分为三个层次,每个层次都有特定的职责和功能。
这种结构的设计思想类似于建筑物的结构,由基础层次、支持层次和应用层次组成,每个层次都对系统的整体性能和稳定性起着重要作用。
基础层次是系统的最底层,它主要负责处理底层硬件和操作系统的功能。
基础层次提供了系统操作的基本功能,包括数据的输入、处理和输出等。
它与硬件密切相关,能够充分利用硬件资源,提高整个系统的性能和稳定性。
在这个层次上,开发者需要具备对底层硬件和操作系统的深入了解,以便更好地控制和管理系统的运行。
支持层次是系统的中间层,它主要负责处理系统的业务逻辑和数据管理。
支持层次可以将底层的数据进行处理和转换,从而提供给上层进行使用。
它同时也是其他层次之间的桥梁,负责协调各个层次之间的通信和交互。
在这个层次上,开发者需要具备熟练的编程和算法知识,以便能够高效地实现系统的功能和业务需求。
应用层次是系统的最顶层,它主要负责处理用户的请求和响应。
应用层次可以通过用户界面与用户进行交互,并将用户的请求转化为底层的数据操作。
它是系统的外部表现,直接与用户进行接触,因此需要具备良好的用户体验和界面设计能力。
在这个层次上,开发者需要具备对用户需求的理解和响应能力,以便为用户提供优质的服务和体验。
三层结构原理提供了一种清晰、可扩展和可维护的系统设计方法。
通过将系统分为不同的层次,可以降低系统的复杂性,提高系统的可用性和可靠性。
同时,三层结构原理也使得系统的开发、测试和维护变得更加容易。
开发者可以根据不同的需求和功能,分别对每个层次进行独立的开发和测试,从而提高系统的开发效率和质量。
总之,三层结构原理是一种强大而灵活的系统设计方法。
它以清晰的层次划分和职责分离为基础,将系统的各个部分相互配合,从而实现系统的高效、稳定和可扩展。
掌握三层结构原理,可以使开发者更好地设计和构建复杂系统,提供更好的用户体验和功能。
三层架构详解范文三层架构是一种软件设计模式,将应用程序分为三个主要层次:表示层、业务逻辑层和数据访问层。
每个层次都具有不同的职责和功能,使得系统更易于维护、扩展和测试。
1.表示层:表示层是用户与系统之间的接口,负责接收用户输入、展示输出结果。
它是系统的外部界面,可以是一个网页、桌面应用程序、移动应用程序等。
表示层通常包括用户界面设计、用户体验设计和前端开发等方面,它负责与用户进行交互,将用户的请求传递给业务逻辑层进行处理,并将处理结果展示给用户。
2.业务逻辑层:业务逻辑层是系统的核心,负责处理系统的业务逻辑。
它包括了业务规则、工作流程和数据处理等方面。
业务逻辑层接收来自表示层的请求,根据业务规则进行数据处理和业务逻辑的计算,最后将结果返回给表示层。
在这个层次上,开发人员可以将系统的业务逻辑进行封装,使得系统的可复用性和可维护性更高。
3.数据访问层:数据访问层是负责对数据进行持久化存储和访问的层次。
它包括了数据库的管理和访问,以及与其他数据源的交互等。
数据访问层将业务逻辑层的数据请求转化为数据库操作,通过与数据库进行交互来进行数据的增删改查。
在这个层次上,开发人员可以实现数据缓存、事务管理、数据访问的优化等功能。
三层架构的主要优点有:1.松耦合:三层架构将整个系统分为三个独立的层次,各层次之间通过接口进行交互,使得各层次之间的耦合度降低。
这样,在修改或拓展其中一层次的功能时,不会对其他层次造成影响,提高了系统的灵活性和可维护性。
2.可扩展性:由于每个层次都有明确的功能和职责,因此可以很容易地拓展系统的功能。
例如,可以通过增加实现新的表示层、业务逻辑层或者数据访问层来实现系统功能的扩展。
3.可测试性:每个层次的功能相对独立,因此可以单独对每个层次进行测试。
这样可以更容易地进行单元测试和集成测试,提高了系统的可测试性和稳定性。
4.可维护性:三层架构将系统分为多个层次,使得每个层次的功能和职责更加清晰明确,减少了系统的复杂性。
三层架构将数据层、应用层和业务层分离,业务层通过应用层访问数据库,保护数据安全,利于负载平衡,提高运行效率,方便构建不同网络环境下的分布式应用;表示层主要作用是接收用户的指令或者数据输入,提交给业务逻辑层做处理,同时负责将业务逻辑层的处理结果显示给用户。
相比传统的应用方式,业务层对硬件的资源要求较低;应用层依据应用规模的不同,所承受的负荷会有较大的差异,另外客户端的数目,应用的复杂程度都会对其造成一定的影响。
ERP三层结构提供了非常好的可扩张性,可以将逻辑服务分布到多台服务器来处理,从而提供了良好的伸缩方案;数据层包括存储数据的数据库服务器和处理数据和缓存数据的组件。
组件将大量使用的数据放入系统的缓存库,以提高数据访问和处理的效率.同时ERP采用大型数据库提供高性能、可靠性高的海量数据存储能力存储ERP的业务数据.三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。
区分层次的目的即为了“高内聚,低耦合”的思想.概念简介1、表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。
3、数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找等。
概述在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。
微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或成为领域层)、表示层。
三层结构原理:3个层次中,系统主要功能和业务逻辑都在业务逻辑层进行处理。
所谓三层体系结构,是在客户端与数据库之间加入了一个“中间层",也叫组件层。
这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上。
三层建构,浅文深教三层建构是一种软件架构模型,也称为三层体系结构或多层体系结构。
它是指将软件系统按照不同层次进行划分,每一层都有不同的功能和责任,并且每一层之间通过明确定义的接口进行通信和交互。
三层建构通常被用于开发大型复杂的软件系统,它可以有效地将系统的不同功能进行分离,提高系统的可维护性、可扩展性和可复用性。
三层建构一般包括表示层、业务层和数据层。
表示层是用户接口层,也称为前端层,它负责与用户进行交互,接收用户的输入和展示系统的输出。
表示层通常包括用户界面、用户交互逻辑和数据呈现。
用户界面可以是Web页面、移动应用程序等,用户交互逻辑负责处理用户输入的数据,并将其传递给业务层进行处理,数据呈现负责将业务层返回的数据展示给用户。
业务层是系统的核心层,它负责处理系统的业务逻辑和业务流程。
业务层通常包括业务逻辑处理、业务流程控制和业务规则验证。
业务逻辑处理负责对用户的请求进行处理,包括数据的处理、计算和转换等,业务流程控制负责协调不同的业务逻辑处理,确保系统按照定义的流程进行操作,业务规则验证负责验证用户输入的数据是否符合系统的规则。
数据层是数据管理层,它负责管理系统中的数据。
数据层通常包括数据访问、数据处理和数据存储。
数据访问负责对数据库进行操作,包括查询、更新、删除等,数据处理负责处理从数据库中获取到的数据,进行必要的处理和转换,数据存储负责将数据保存到数据库中,并且提供数据的持久化和恢复功能。
三层建构的优点是明确了各个层次的功能和责任,使得系统更易于维护和扩展。
它将系统的业务逻辑和数据操作进行分离,使得系统更易于编写和测试。
三层建构还提供了良好的可复用性和可移植性,可以方便地将各个层进行替换和升级。
三层建构也存在一些缺点。
由于将系统按照不同的层进行划分,可能导致系统的复杂性增加,特别是在处理分层之间的交互和通信时。
三层建构可能导致系统的性能下降,特别是在数据的传输和转换时,需要进行额外的处理和计算。
浅谈“三层结构”的原理与用意对于有经验的Web应用程序开发人员来说,“三层结构”一词应该不会感到陌生。
其实“三层结构”的开发模式不仅仅可以应用于Web应用程序,在其他应用领域也是可以发挥其巨大作用的。
而本文主旨是阐明三层结构的原理与用意,并说明Bincess的三层结构的特点。
“三层结构”一词中的“三层”是指:“外观层”、“中间层”、“数据库层”。
其中:☐外观层:位于最外层,直接呈现在用户面前。
用于显示数据,并为用户提供一种交互式的界面。
☐中间层:负责处理用户输入的信息,或者是将这些信息发送给数据库层进行保存,或者是调用数据库层中的函数再次读出这些数据。
☐数据库层:仅实现对数据的保存和读取操作。
为什么需要“三层结构”在一个软件系统中,如果不分以层次,那么在将来的升级维护中会遇到很大的麻烦。
就像一个网页访问数据库一样。
例如在后台程序文件aspx.cs中,使用OleDbConnection和OleDbCommand来处理Access 后台数据库。
而当数据库服务器从Access2000升迁到SQLServer2000的时候,我们就必须修改原来的OleDbConnection为新的SqlConnection,OleDbCommand为新的SqlCommand来适应新的数据库服务器。
但问题是对于一个大型的商业网站,要进行数据库操作的并不只有一两个页面。
访问数据库的代码会散落各个页面中,就像夜空中的星星一样。
这样的维护,难度可想而知。
有一个比较好的解决办法,那就是将访问数据库的代码全部都放在一个cs文件里,这样数据库服务器一旦变换,那么只需要集中修改一个cs文件就可以了。
将原来的访问数据库的代码全部都放在DBTask.cs程序文件中,这样只要修改这一个文件就可以适应新的数据库当然这是一个简单的“门面模式”的应用,恐怕也是“三层结构”的最原始模型…怎样才算是一个符合“三层结构”的Web应用程序?在一个 Web应用程序解决方案中,并不是说有aspx文件、有dll文件、还有数据库,就是“三层结构”的Web应用程序,这样的说法是不对的。
三层架构详细的介绍了三层架构
三层架构是当前计算机网络技术中一种常用的模型,它将整个网络系
统分成三个不同的层次:应用层、传输层和网络层。
三层架构的设计概念
是“分而治之”,即把整个网络的工作任务分解成若干个独立的层,每个
层对下面一层只有非常有限的了解,而且不用理会其他层的活动情况,只
负责和本层有直接关系的活动,从而使网络的复杂性降低,操作用户也更
加容易掌握。
下面将详细介绍三层架构的每一层内容。
(一)应用层
应用层是计算机网络中最高的一层,它的主要功能是负责为用户提供
服务,为用户实现与网络的交互和通信,并且能够完成数据传输的功能。
应用层的技术包括:FTP(文件传输协议)、SMTP(简单邮件传输协议)、HTTP(超文本传输协议)、TELNET(网络终端协议)、SNMP(简单网络管
理协议)等协议,都是在应用层完成其功能。
(二)传输层
传输层是一个中间层,它的主要功能是完成数据的传输、控制和检验
操作,并且能够在发送端和接收端之间建立可靠的数据传输链路。
三层架构的理解范文三层架构是指在软件系统开发过程中将系统划分为三个层次,每个层次有不同的功能和责任。
它是一种常用的架构设计模式,用于实现软件系统的可维护性、可扩展性和可重用性,具有很高的灵活性和可靠性。
三层架构由以下三个层次组成:表示层(或用户界面层)、业务逻辑层和数据访问层。
下面将逐层进行详细介绍。
1.表示层(用户界面层):表示层是用户与系统之间的界面,主要负责接收用户的请求并显示系统的响应结果。
它可以是网页、桌面应用程序、移动应用程序等形式。
表示层通过调用业务逻辑层的接口来处理用户的请求,并将结果展示给用户。
它负责用户界面的呈现,包括页面布局、控件和元素等。
2.业务逻辑层:业务逻辑层是整个系统的核心,负责处理与业务逻辑相关的操作。
它接收表示层的请求,根据业务规则进行处理,并通过调用数据访问层来执行数据库操作。
在这个层次上,开发人员需要对业务进行分析和抽象,将业务逻辑转化为代码实现。
业务逻辑层主要包括各种业务逻辑的实现、数据校验和数据处理等。
3.数据访问层:数据访问层主要负责与数据库进行交互,对数据库进行增、删、改和查等操作,将数据保存到数据库或从数据库中读取数据。
它封装了数据库的操作细节,提供了一组接口供业务逻辑层使用。
数据访问层的设计需要考虑数据库的类型、操作方式和连接方式等,保证数据的安全性和完整性。
1.模块化:三层架构将系统划分为三个独立的层次,使得每个层次都具有独立的功能和责任。
这样可以提高代码的复用性,减少系统模块之间的耦合度。
2.可维护性:由于每个层次都有明确的功能和职责,因此当需要对系统进行扩展或修改时,只需对相应的层次进行修改,而不会影响到其他层次。
这样可以降低系统维护的难度和成本。
3.可扩展性:三层架构能够支持系统的可扩展性,当需求发生变化时,可以对一些层次进行扩展或替换,而不会对其他层次造成影响。
4.安全性:三层架构能够通过对不同层次的合理划分来保证系统的安全性。
通过控制数据访问层的权限,可以有效防止非法访问和数据泄露。
这是我在网上的看到的
三层结构为:
1.表示层(USL):主要表示WEB方式,也可以表示成WINFORM方式。
如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。
2.业务逻辑层(BLL):主要是针对具体的问题的操作,也可以理解成对数据层的操作,对数据业务逻辑处理。
如果说数据层是积木,那逻辑层就是对这些积木的搭建。
3.数据访问层(DAL):主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据的操作,而不是数据库,具体为业务逻辑层或表示层提供数据服务。
这是我自己理解的:
UI 界面层就是用户能看见或操作的
BLL(Business Logic Layer) 业务逻辑层
就是为界面层提供判断的一层
例如:BLL层判断用户界面登录是否合法成功是返回一个真值反之返回false
而界面层根据BLL 返回的值弹出登录成功或失败的相应的界面
DAL(Data Access Layer) 数据访问层这个就好理解了就是一些对数据库的基本操作如增删改查等。
一、三层架构的介绍:三层架构,是为了便于我们开发项目后维护及变更的一种有效而实用的架构模式,在各种B/S项目中被广泛的采用着.首先让我们来认识一下三层结构及每一层之前的作用和调用关系。
三层,即:数据访问层(DAL):主要是对数据的增、删、改、查操作。
业务逻辑层(BLL):包含了项目中的业务逻辑,负责调用DAL中的方法实现业务的处理,并在表示层与数据访问层之间起到衔接的作用。
表示层(WebUI):用于显示数据和接受用户输入数据的一层,即为用户界面。
二、三层架构的实现:1、将表抽象成模型首先让我们以一个用户注册的例子来为大家举例,并通过这一例子进而了解三层架构应用现有数据库Database,表与字段如下:Admin 用户表AdminId 用户Id int 自增长 PKUserName 用户名 nvarchar(50)PassWord 密码 nvarchar(50)RoleId 角色Id int FK->Role表Role 角色表RoleId 角色Id int 自增长 PKRoleName 角色名称 nvarchar(50)好了,现在我们已知了两张表及其字段,下面我们可以将其抽象成类以便于我们以对象的形式在各个层之间的传输和调用(我们把与表对应的类单独建一个类库存储,并命名为Models,即模型)*注:以下代码全部省略命名空间引用部份,见谅[Serializable] //序列化便于传输public class Admin //与表明对应的类名{private int adminId; //字段抽象成属性public int AdminId //封装字段{get { return adminId; }set { adminId = value; }}private string userName;public string UserName{get { return userName; }set { userName = value; }}private string passWord;public string PassWord{get { return passWord; }set { passWord = value; }}private Role role; //由于主外键关系,我们将外键的引用以对象的形式保存在主键体现的类中public Role Role{get { return role; }set { role = value; }}}*Role类的代码省略至此,我们已经将业务中所用到的表抽象为了两个类以便于我们操作,下面,是书写IService接口的时候了~2、写好接口,便于规范DAL方法(我们在这里将接口的类库命名为IService)有了Models提供的类,我们可以根据类来书写接口了,由于我们只以用户的注册为例,所以我们在这里只书写两个方法public interface IAdminService{int AddAdmin(string userName,string passWord,int roleId); //根据用户名密码和选择的角色来注册int AddAdmin(Admin admin); //根据一个用户对象进行注册}接口是一个方法的规范,它不需要具体的实现,只需要描述一个方法的参数和返回值即可,是不是很简单呢?有了这些方法的接口,我们就该写实现类了3、遵循接口,实现DAL方法有了接口,我们下面来真正的开始写数据库操作的方法*注省略传统的SqlHelper方法(即通用的数据库类,其中包含数据库的连接方法和基本增删改查方法,与业务无关),我们讲以业务方法为主要介绍对象public class AdminService:IAdminService //实现IAdminService接口{public int AddAdmin(string userName, string passWord, int roleId) //实现AddAdmin方法参数用户名密码角色Id{string strSQL = "spAddAdmin"; //调用存储过程SqlParameter[] paras = new SqlParameter[] //设置存储过程参数数组{new SqlParameter("@UserName",userName),new SqlParameter("@PassWord",passWord),new SqlParameter("@RoleId",roleId)};return SqlHelper.ExecuteCommand(strSQL, paras); //调用SqlHelper类的通用更新方法}public int AddAdmin(Admin admin) //同上参数用户对象{string strSQL = "spAddAdmin";SqlParameter[] paras = new SqlParameter[]{new SqlParameter("@UserName",erName),new SqlParameter("@PassWord",admin.PassWord),new SqlParameter("@RoleId",admin.Role.RoleId)};return SqlHelper.ExecuteCommand(strSQL, paras);}}OK,至此,我们的DAL层中的类书写完毕,下面我们来一起看一看它们是如何在BLL层中调用并传递给WebUI的吧~4、BLL层调用DAL,传递至WebUI我们现在已经有了在DAL中对于用户注册的方法,下面我们只需要书写一个用户的业务类,并且调用该方法即可实现用户的注册功能(我们把这些方法统一放在一个名为BLL的类库中)public class AdminManager //BLL中Admin的业务类名{[DataObjectMethod(DataObjectMethodType.Insert)] //声明该方法类型为插入 public static int AddAdmin(string username, string password, int roleid)//静态用户注册方法,提供用户名密码角色Id 3参数,返回int型便于表示层判断{AdminService as = new AdminService(); //创建一个DAL中的AdminService 类对象return as.AddAdmin(username,password,roleId); //调用DAL方法执行注册 //returnAbstractFactory.ChooseFactory().CreateAdminService().AddAdmin(username, password, roleid); //通过抽象工厂,调用DAL中的静态方法抽象工厂会在后面作为拓展介绍}[DataObjectMethod(DataObjectMethodType.Insert)] //同上public static int AddAdmin(Admin admin) //静态用户注册方法提供用户对象参数返回int型{AdminService as = new AdminService();return as.AddAdmin(username,password,roleId); //调用DAL方法执行注册 //returnAbstractFactory.ChooseFactory().CreateAdminService().AddAdmin(admin);}}全部的业务我们都已经完成了,下面,我们唯一要做的就是在表示层中看一看它们如何调用BLL的,并且如何处理返回的结果的5、表示层的应用表示层所关注的仅仅是BLL层中的方法,因此,我们在表示层中也只需引用BLL层,然后调用方法即可,我们仍旧继续我们的登录操作,请看代码:protected void btnLogin_Click(object sender, EventArgs e) //按钮点击提交方法 {if (AdminManager.AddAdmin(txtUserName.Text,txtPassWord.Text,txtRoleId.Text) > 0) //调用BLL中的方法,判断是否注册成功{//注册成功HttpCookie cookieTime = new HttpCookie("LoginInfo"); //写入Cookie 下略,在这里我们只关注三层cookieTime.Values["LoginTime"] = DateTime.Now.ToString();cookieTime.Values["LoginAddress"] = erHostAddress;cookieTime.Expires = DateTime.Now.AddDays(3);Response.Cookies.Add(cookieTime);Session["AdminInfo"] = AdminManager.AdminLogin(txtUserName.Text, txtPassWord.Text)[0];Response.Redirect("~/Default.aspx"); //跳转页}else //注册失败{Response.Write("注册失败"); //提示信息}}致此,关于的3层架构就全部介绍完了我们来将其要点和调用关系在汇总一下首先我们要讲数据库的每个表抽象成一个对应的类,如果有主外键关系,则以对象的形式引用(Models)然后,我们开始书写规范DAL方法的接口,在这里我们需要考虑到所用到的参数和返回值(IService)*引用Moldes有了接口,我们可以就去实现DAL中的相对应方法了(DAL)*引用Moldes 引用IService然后,我们在BLL层中,我们调用DAL中的方法 *引用Models 引用DAL(如果采用抽象工厂模式,则引用IService)最后,我们在视图层中调用BLL中的业务方法,实现3层之间相互的业务调用 *仅引用BLL关于3层架构就介绍到这里,关于抽象工厂,稍晚时候将做介绍,谢谢~。
浅谈“三层结构”的原理与用意对于有经验的Web应用程序开发人员来说,“三层结构”一词应该不会感到陌生。
其实“三层结构”的开发模式不仅仅可以应用于Web应用程序,在其他应用领域也是可以发挥其巨大作用的。
而本文主旨是阐明三层结构的原理与用意,并说明Bincess的三层结构的特点。
“三层结构”指的是什么?“三层结构”一词中的“三层”是指:“外观层”、“中间层”、“数据库层”。
其中:☐外观层:位于最外层,直接呈现在用户面前。
用于显示数据,并为用户提供一种交互式的界面。
☐中间层:负责处理用户输入的信息,或者是将这些信息发送给数据库层进行保存,或者是调用数据库层中的函数再次读出这些数据。
☐数据库层:仅实现对数据的保存和读取操作。
为什么需要“三层结构”在一个软件系统中,如果不分以层次,那么在将来的升级维护中会遇到很大的麻烦。
就像一个网页访问数据库一样。
例如在后台程序文件aspx.cs中,使用OleDbConnection和OleDbCommand来处理Access 后台数据库。
而当数据库服务器从Access2000升迁到SQLServer2000的时候,我们就必须修改原来的OleDbConnection为新的SqlConnection,OleDbCommand为新的SqlCommand来适应新的数据库服务器。
但问题是对于一个大型的商业网站,要进行数据库操作的并不只有一两个页面。
访问数据库的代码会散落各个页面中,就像夜空中的星星一样。
这样的维护,难度可想而知。
有一个比较好的解决办法,那就是将访问数据库的代码全部都放在一个cs文件里,这样数据库服务器一旦变换,那么只需要集中修改一个cs文件就可以了。
namespace Bincess // ListBoard.aspx.cs文件{public class ListBoard{private void BoardDataBind(){OleDbConnection dbConn=new OleDbConnection();OleDbCommand dbCmd=new OleDbCommand();...}}}namespace Bincess // ListTopic.aspx.cs文件{public class ListTopic{private void TopicDataBind(){OleDbConnection dbConn=new OleDbConnection();OleDbCommand dbCmd=new OleDbCommand();...}} 注意,这两个文件都进行了数据库操作。
那么在数据库服务器改换时,两个文件就都必须修改并重新编译…将原来的访问数据库的代码全部都放在DBTask.cs 程序文件中,这样只要修改这一个文件就可以适应新的数据库 namespace Bincess// DBTask.cs {public class DBTask{public void BoardDataBind() {OleDbConnection dbConn=new OleDbConnection();OleDbCommand dbCmd=new OleDbCommand();...}public void TopicDataBind(){OleDbConnection dbConn=new OleDbConnection();OleDbCommand dbCmd=new OleDbCommand();...}} }namespace Bincess// ListBoard.aspx.cs 文件 {public class ListBoard{private void BoardDataBind(){(new DBTask()).BoardDataBind(); }}}namespace Bincess// ListTopic.aspx.cs 文件 {public class ListTopic{private void TopicDataBind(){(new DBTask()).TopicDataBind();}} }当然这是一个简单的“门面模式”的应用,恐怕也是“三层结构”的最原始模型…定义一个DBTask 类,让它来完成所有的数据库操作。
那么当数据库服务器改换时,只要集中修改这一个文件并重新编译即可…怎样才算是一个符合“三层结构”的Web应用程序?在一个 Web应用程序解决方案中,并不是说有aspx文件、有dll文件、还有数据库,就是“三层结构”的Web应用程序,这样的说法是不对的。
也并不是说没有对数据库进行操作,即没有“数据库层”,就不是“三层结构”的。
其实三层结构是功能实现上的三层:☐外观层,用于显示,并为用户提供交互式操作的可能…☐中间层,服务于外观层并调用数据库层的函数。
☐数据库层,实现数据库的存储和读出。
存储目标不一定是数据库服务器,也可以是文本文档或XML文档。
在微软的示范实例Duwamish7中,外观层被放置在Web项目中,中间层是放置在BusinessFacade项目中,而数据库层则是放置在DataAccess项目中。
而微软的另一个示范实例PetShop中,外观层被放置在Web项目中,中间层是放置在BLL项目中,而数据库层则是放置在SQLServerDAL和OracleDAL两个项目中。
在我的彬月论坛中,外观层是被放置在Web项目中,中间层是被放置在InterService项目中,而数据库层是被放置在AccessTask项目中。
显然PetShop要比Duwamish7复杂的多!如果先不讨论这些,那么现在的问题就是:既然三层结构已经被分派到各自的项目中,那么剩下来的项目是做什么的呢?例如PetShop中的Model、IDAL、DALFactory这三个项目,再例如Duwamish7中的Common项目,还有就是在我的论坛中的Classes、DBTask、DALFactory三个项目。
它们是做什么用的呢?我想下面的文字会慢慢让你明白的。
从Nokia的手机生产线说起一个“三层结构”的Web应用程序,就象是Nokia公司的手机生产线。
☐Web层就像是公司的经理,他负责洞察市场趋势,决策产品的生产。
并根据市场筹策下一步计划。
☐InterService就像是公司的管理员,他主要负责管理下层员工,传达上级布置的生产任务给员工,并将生产结果反馈给上级Web。
☐AccessTask就是公司里的工人,他们主要是负责手机产品的生产装配工作,并将生产结果反馈给上级InterService。
他们并不需要知道产品将销往何处,也不用关心产品销量。
只要能完成任务,就可以拿到报酬。
命令方向是自上而下的,而结果反馈方向则是自下而上的。
根据这个图例来简要的描述彬月论坛中的留言板显示功能,那么代码应该是:<!--//首先是ListLeaveWord.aspx这个文件//--><Asp:Repeater id=″leaveWordRepeater″Runat=″SERVER″><ItemTemplate><%# DataItem.Eval(Container.DataItem, ″Content″) %></ItemTemplate>这样便完成了对留言板的访问和显示,箭头所指的方向就是命令的方向。
虽然这符合“三层结构”开发模式的思想,但是这却存在着重大的漏洞,或者说是重大缺陷!为什么会这么说呢?因为从中间层返回的结果是不安全的!而造成中间层返回结果不安全的原因是从数据库层返回的结果并不确切!这会造成外观层过于脆弱,这并不是一个“强”三层结构。
还是用代码来说明。
假如,LeaveWordDBTask.cs文件中的List方法实现是这样的://位于数据库层的 LeaveWordDBTask.cs 文件namespace AccessTask{public class LeaveWordDBTask{public void List(DataSet ds){string cmdText=″SELECT * FROM [RegUser]″; //注意这里,访问的不是LeaveWord数据表OleDbConnection dbConn=new OleDbConnection(″...″);OleDbDataAdapter dbAdp=new OleDbDataAdapter(cmdText, dbConn);dbAdp.Fill(ds, ″LeaveWord″); //但是也填充了DataSet}}那么回逆到文件LeaveWordService.cs的List函数,再回逆到ListLeaveWord.aspx.cs文件的LeaveWordDataBind 函数。
把数据绑定到重复器上,而在显示的时候,会提示:找不到Content字段!<Asp:Repeater id=″leaveWordRepeater″Runat=″SERVER″><ItemTemplate><%# DataItem.Eval(Container.DataItem, ″Content″) %><-- 在这里会出现错误提示</ItemTemplate></Asp:Repeater>出现这样的结果并不奇怪,因为数据库层访问的是RegUser数据表,而RegUser数据表中并没有定义Content字段。
外观层因此变得很脆弱,这也使得页面设计师和数据库编程人员产生了不应有的交涉。
仅仅为了达到程序可运行目的,数据库编程人员就必须小心翼翼的写每句代码。
这就像是NoKia公司的经理发布生产命令后,得到的返回结果却是生产线上的员工生产装配了好几台电视?!这当然不是经理们想要的结果。
但为什么会有这样结果呢?因为经理们在发布生产命令时,忘记说明产品的规格和特征了。
经理一声令下:“生产!”——(new LeaveWordService()).List(DataSet ds)但是却没有对产品的规格特征作详细说明?例如手机的型号、外观等等。
这里的ds就相当于所要生产的产品集合,但却没有作细部说明…那么怎样才能避免这样荒唐的结果出现呢?经理在发布生产命令之前,应该规定产品的规格特征!那么原来的示意图应该也发生一些变化:相应的代码也要变化:这样,即便是将LeaveWordTask.List方法修改成访问RegUser数据表的代码,也依然不会影响到外观层。
再执行期间系统会抛出异常,而这个异常信息肯定是再数据库层。
再有,因为位于外观层的重复器控件绑定的是数据库层返回结果的目的。