三层架构(我的理解及详细分析)

合集下载

三层架构详解范文

三层架构详解范文

三层架构详解范文三层架构是一种软件设计模式,将应用程序分为三个主要层次:表示层、业务逻辑层和数据访问层。

每个层次都具有不同的职责和功能,使得系统更易于维护、扩展和测试。

1.表示层:表示层是用户与系统之间的接口,负责接收用户输入、展示输出结果。

它是系统的外部界面,可以是一个网页、桌面应用程序、移动应用程序等。

表示层通常包括用户界面设计、用户体验设计和前端开发等方面,它负责与用户进行交互,将用户的请求传递给业务逻辑层进行处理,并将处理结果展示给用户。

2.业务逻辑层:业务逻辑层是系统的核心,负责处理系统的业务逻辑。

它包括了业务规则、工作流程和数据处理等方面。

业务逻辑层接收来自表示层的请求,根据业务规则进行数据处理和业务逻辑的计算,最后将结果返回给表示层。

在这个层次上,开发人员可以将系统的业务逻辑进行封装,使得系统的可复用性和可维护性更高。

3.数据访问层:数据访问层是负责对数据进行持久化存储和访问的层次。

它包括了数据库的管理和访问,以及与其他数据源的交互等。

数据访问层将业务逻辑层的数据请求转化为数据库操作,通过与数据库进行交互来进行数据的增删改查。

在这个层次上,开发人员可以实现数据缓存、事务管理、数据访问的优化等功能。

三层架构的主要优点有:1.松耦合:三层架构将整个系统分为三个独立的层次,各层次之间通过接口进行交互,使得各层次之间的耦合度降低。

这样,在修改或拓展其中一层次的功能时,不会对其他层次造成影响,提高了系统的灵活性和可维护性。

2.可扩展性:由于每个层次都有明确的功能和职责,因此可以很容易地拓展系统的功能。

例如,可以通过增加实现新的表示层、业务逻辑层或者数据访问层来实现系统功能的扩展。

3.可测试性:每个层次的功能相对独立,因此可以单独对每个层次进行测试。

这样可以更容易地进行单元测试和集成测试,提高了系统的可测试性和稳定性。

4.可维护性:三层架构将系统分为多个层次,使得每个层次的功能和职责更加清晰明确,减少了系统的复杂性。

三层架构简易实例详解

三层架构简易实例详解

三层架构简易实例详解何为三层架构?通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。

区分层次的目的即为了“高内聚,低耦合”的思想。

1.表现层(UI):即展现给用户的界面;2.业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理;3.数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、查找等。

下面通过通过一个简单的例子来描述三层架构:需求1.实现一个客户信息管理界面(包括增加、修改、删除)操作;2.用户sql—server作为数据库以下是成型界面,至于UI设计是否合理,望各位大神拍砖UI层设计设计器代码:<Grid><DockPanel><ToolBar DockPanel.Dock="Top" Height="30"><Button Name="BtnAdd" Click="BtnAdd_Click" ToolTip="新增"><Image Source="Image\add.ico"></Image></Button><Button Name="BtnEdit" Click="BtnEdit_Click" ToolTip="编辑"><Image Source="Image\edit.ico"></Image></Button><Button Name="BtnDel" Click="BtnDel_Click" ToolTip="删除"><Image Source="Image\delete.ico"></Image></Button></ToolBar><DataGrid Name="DataGrid1" DockPanel.Dock="Top" IsReadOnly="True" AutoGenerateColumns="False"><DataGrid.Columns><DataGridTextColumn Header="姓名" Binding="{Binding Name}"></DataGridTextColumn><DataGridTextColumn Header="生日" Binding="{Binding BirthDay}"></DataGridTextColumn><DataGridTextColumn Header="电话" Binding="{Binding TelNum}"></DataGridTextColumn><DataGridTextColumn Header="地址" Binding="{Binding Address}"></DataGridTextColumn><DataGridTextColumn Header="等级" Binding="{BindingCustlevel}"></DataGridTextColumn></DataGrid.Columns></DataGrid></DockPanel></Grid>主要是通过设计器后台代码,DataGrid控件绑定数据,代码如下:/// <summary>/// 初始化加载数据/// </summary>private void LoadData(){DataGrid1.ItemsSource = CustomDAL.GetAll();}数据业务逻辑代码如下:/// <summary>/// 新增/// </summary>/// <param name="sender"></param>/// <param name="e"></param>private void BtnAdd_Click(object sender, RoutedEventArgs e){CustomEditUI editUI = new CustomEditUI();editUI.isInsert = true;if (editUI.ShowDialog() == true){LoadData();}}/// <summary>/// 编辑/// </summary>/// <param name="sender"></param>/// <param name="e"></param>private void BtnEdit_Click(object sender, RoutedEventArgs e){Custom customer = (Custom)DataGrid1.SelectedItem;if (customer == null){MessageBox.Show("请选择要编辑的行!");return;}CustomEditUI editUI = new CustomEditUI();//添加标识便于区分是编辑保存还是新增保存editUI.isInsert = false;editUI.editId = customer.Id;if (editUI.ShowDialog() == true){LoadData();}}/// <summary>/// 删除/// </summary>/// <param name="sender"></param>/// <param name="e"></param>private void BtnDel_Click(object sender, RoutedEventArgs e){if (MessageBox.Show("确认删除此条数据?", "提醒", MessageBoxButton.YesNo) == MessageBoxResult.Yes){Custom custom = DataGrid1.SelectedItem as Custom;if (custom != null){if ((MessageBox.Show("确认要删除此调数据", "提醒") == MessageBoxResult.OK)){CustomDAL.Delete(custom.Id);LoadData();}}else{MessageBox.Show("请选择要删除的数据", "提醒");return;}}}数据访问层(DAL),代码如下:public class CustomDAL{/// <summary>/// 查询数据总条数/// </summary>/// <returns></returns>public static int GetCount(){return (int)SqlHelper.ExecuteScalar("select * from T_Custom");}/// <summary>///根据ID查询数据/// </summary>/// <param name="id"></param>/// <returns></returns>public static Custom GetByid(long id){DataTable table = SqlHelper.ExecuteDataTable("select * from T_custom where id=@id", new SqlParameter("@id", id));return ToCustom(table.Rows[0]); ;}/// <summary>/// 根据id删除数据/// </summary>/// <param name="id"></param>public static void Delete(long id){SqlHelper.ExecuteNonQuery("delete from T_custom where id=@id", new SqlParameter("@id", id));}/// <summary>/// 插入空值处理/// </summary>/// <param name="value"></param>/// <returns></returns>public static object FromDBNull(object value){if (value == null){return DBNull.Value;}else{return value;}}/// <summary>/// 查询空值处理/// </summary>/// <param name="value"></param>/// <returns></returns>public static object ToDBNull(object value){if (DBNull.Value == null){return null;}else{return value;}}/// <summary>/// 新增数据/// </summary>/// <param name="custom"></param>public static void InSert(Custom custom){SqlHelper.ExecuteNonQuery(@"insert into T_Custom(Name,Birthday,Address,Telnum,Custlevel)values(@Name,@Birthday,@Address,@Teln um,@Custlevel)",new SqlParameter("@Name", ),new SqlParameter("@Birthday", FromDBNull(custom.BirthDay)),new SqlParameter("@Address", custom.Address),new SqlParameter("@Telnum", custom.TelNum),new SqlParameter("@Custlevel", custom.Custlevel));}/// <summary>/// 更新数据/// </summary>/// <param name="custom"></param>public static void UpDate(Custom custom){SqlHelper.ExecuteNonQuery(@"update T_Custom set Name=@Name,Birthday=@Birthday,Address=@Address,Telnum=@Telnum,Custlevel=@Custlevel where id=@id",new SqlParameter("@Name", ),new SqlParameter("@Birthday", FromDBNull(custom.BirthDay)),new SqlParameter("@Address", custom.Address),new SqlParameter("@TelNum", custom.TelNum),new SqlParameter("@Custlevel", custom.Custlevel),new SqlParameter("@Id", custom.Id));}/// <summary>/// 查询所有数据/// </summary>/// <returns></returns>public static List<Custom> GetAll(){DataTable table = SqlHelper.ExecuteDataTable("select * from T_custom");List<Custom> lst = new List<Custom>();for (int i = 0; i < table.Rows.Count; i++){lst.Add(ToCustom(table.Rows[i]));}return lst;}/// <summary>/// 影射关系赋值/// </summary>/// <param name="row"></param>/// <returns></returns>public static Custom ToCustom(DataRow row){Custom custom = new Custom(); = row["Name"].ToString();custom.Address = row["Address"].ToString();custom.BirthDay = (DateTime?)ToDBNull(row["BirthDay"]);custom.TelNum = row["TelNum"].ToString();custom.Custlevel = (int)row["CUstlevel"];custom.Id = (long)row["id"];return custom;}}public class SqlHelper{private static string connstr = ConfigurationManager.ConnectionStrings["conn"].ConnectionString;/// <summary>/// 查询数据/// </summary>/// <param name="sql"></param>/// <param name="parameters"></param>/// <returns></returns>public static Object ExecuteScalar(string sql, params SqlParameter[] parameters){using (SqlConnection cnn = new SqlConnection(connstr)){cnn.Open();using (SqlCommand cmd = cnn.CreateCommand()){mandText = sql;cmd.Parameters.AddRange(parameters);return cmd.ExecuteScalar();}}}/// <summary>/// 增、删、改操作/// </summary>/// <param name="sql"></param>/// <param name="parameters"></param>public static void ExecuteNonQuery(string sql, params SqlParameter[] parameters){using (SqlConnection cnn = new SqlConnection(connstr)){cnn.Open();using (SqlCommand cmd = cnn.CreateCommand()){mandText = sql;cmd.Parameters.AddRange(parameters);cmd.ExecuteNonQuery();}}}/// <summary>/// 单个查询结果返回/// </summary>/// <param name="sql"></param>/// <param name="parameters"></param>/// <returns></returns>public static DataTable ExecuteDataTable(string sql, params SqlParameter[] parameters){using (SqlConnection cnn = new SqlConnection(connstr)){cnn.Open();using (SqlCommand cmd = cnn.CreateCommand()){mandText = sql;cmd.Parameters.AddRange(parameters);SqlDataAdapter apter = new SqlDataAdapter(cmd);DataSet dataset = new DataSet();apter.Fill(dataset);return dataset.Tables[0];}}}}业务模型层public class Custom{public long Id { set; get; }public string Name { set; get; }public DateTime? BirthDay { set; get; }public string Address { set; get; }public string TelNum { set; get; }public int Custlevel { set; get; }}业务模型层public class Custom{public long Id { set; get; }public string Name { set; get; }public DateTime? BirthDay { set; get; }public string Address { set; get; }public string TelNum { set; get; }public int Custlevel { set; get; } }上述用思想,图形表示如下:。

三层架构简易实例详解

三层架构简易实例详解

三层架构简易实例详解三层架构是一种软件设计模式,它将软件系统分为三个层次:表现层、业务逻辑层和数据访问层。

每个层次都有特定的职责,通过分层的方式提高了系统的可维护性、可扩展性和可复用性。

以下是一个简单的示例来解释三层架构的概念:1. 表现层(Presentation Layer):这是用户与系统交互的界面。

它负责接收用户的输入、展示数据和呈现界面效果。

可以使用 Web 页面、桌面应用程序或移动应用程序等来实现。

2. 业务逻辑层(Business Logic Layer):该层处理系统的核心业务逻辑。

它接收来自表现层的请求,执行相应的业务规则和计算,并与数据访问层进行交互以获取和保存数据。

3. 数据访问层(Data Access Layer):这一层负责与数据库或其他数据源进行交互。

它封装了数据的读取、写入、修改和查询操作,提供了一个统一的数据访问接口。

以下是一个简单的示例,以在线书店为例:1. 表现层:用户通过网站或移动应用程序浏览图书列表、查看图书详细信息、添加到购物车和进行结算。

2. 业务逻辑层:处理用户的请求,例如检查购物车中的图书数量、计算价格、应用折扣等。

它还负责与数据访问层交互以获取图书信息和保存用户的订单。

3. 数据访问层:与数据库进行交互,执行图书的查询、插入、更新和删除操作。

通过将系统划分为三层,每层专注于特定的职责,可以提高代码的可维护性和可复用性。

当需求发生变化或需要进行系统扩展时,只需修改相应层次的代码,而不会影响其他层次。

这种分层的架构也有助于团队协作和开发效率。

请注意,这只是一个简单的示例,实际的三层架构应用可能会更加复杂,并涉及更多的模块和技术。

具体的实现方式会根据项目的需求和规模而有所不同。

三层架构的理解

三层架构的理解

对三层架构的理解(个人感悟)本人和大家一样,刚刚步入工作,在一家网络公司做 开发,面试的时候经理问我,你对三层架构的理解,当时在学习的时候只是偶然看到书上的解释,我也只是记住了名字而已,我就回答说:表现层,逻辑层,数据层,把经理给唬过去了,(估计他也不懂。

开个玩笑)。

刚刚做完一个项目,虽然只是花了一个星期的小项目,一个人独立完成。

做完之后,问题来了,做了一个后台管理,其中一个cs里面竟然有一千多行代码,当时客户提出问题,当我修改源码的时候,我看的那是个头晕啊,原因是什么,1000多行代码,找又难找,而且所有方法写在一块,不晕才怪。

吃了一回苦头,回家找找问题,在网上查了一些关于三层的资料,下面就我开发项目的经验,和一些资料谈谈我对三层的见解,我认为我写的东西应该很容易看懂的,初学者可以认真看看。

保证能看懂。

进入正题:三层架构,哪三层?USL(User Show Layer)表现层—通俗点说就是给客户看的。

BLL(Business Logic Layer)业务逻辑层—对数据逻辑的处理。

DAL(Data Access Layer)数据访问层—对数据库操作。

我当时有个疑问,为什么要有三层,我们面向对象不是挺方便的,用户登录—检查用户名、密码—连接数据库对比数据,刚好三个方法,调用三个函数,搞定。

当然,对于这种简单的,单页面的web,代码量少的页面,可以不分层,分层反而显得麻烦,减缓运行速度,如果是做一个项目,20几个页面,如果不分层,那就会出现像我刚刚说的,1000多行代码,看的眼花,而且不好修改。

三层怎么用?就拿FileUpload,Reaperter来说吧。

FileUpload:USL 当然放页面,呈现给用户,使用者看。

BLL层可以做检查文件是否为空,文件大小等,限制上传大小也得在BLL做,有很多人把BLL当作一个传值层,不可取,其实BLL能做很多东西,仅次于DAL的重要性,所有要懂得灵活运用BLL层。

三层架构 BS架构

三层架构 BS架构

B/S结构简化了客户机的工作,把二层C/S结构的事务处理逻辑模块从客户机的任务中分离出来,由Web服务器单独组成一层来负担其任务,从而减轻了客户机的压力三层架构(3-tier三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。

区分层次的目的即为了“高内聚,低耦合”的思想。

1、表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。

2、业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。

3、数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找等。

在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。

微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或成为领域层)、表示层。

三层结构原理:3个层次中,系统主要功能和业务逻辑都在业务逻辑层进行处理。

所谓三层体系结构,是在客户端与数据库之间加入了一个“中间层”,也叫组件层。

这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上。

三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。

通常情况下,客户端不直接与数据库进行交互,而是通过COM/DCOM 通讯与中间层建立连接,再经由中间层与数据库进行交互。

表示层位于最外层(最上层),离用户最近。

用于显示数据和接收用户输入的数据,为用户提供一种交互式操作的界面。

业务逻辑层业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分。

它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,很多时候,也将业务逻辑层称为领域层。

三层架构详解范文

三层架构详解范文

三层架构详解范文
三层架构是由客户端(终端)-服务器端(网络)-数据库服务器(数
据库)组成的三层结构,主要应用于客户端和服务器之间的应用架构,为
客户端和服务器之间的通信和数据存储提供一种简单、高效、可靠的解决
方案。

一、客户端:客户端是三层架构的直接参与者,它完成了用户的信息
执行功能。

它容易被用户认可,用户可以快速完成基本的操作。

客户端可
以有各种形式,如PC,移动端,Web应用等。

二、服务器端:服务器端是三层架构的核心,它充当着客户端和数据
库服务器之间数据传输的桥梁或中介。

它收到客户端的请求,然后向数据
库服务器发出信息查询请求,从而获得需要的数据。

它把客户端发来的请
求和服务端自身的其他功能结合起来,完成客户端的数据查询和处理功能,进而把处理好的数据回传给客户端,实现数据的快速查找和处理。

三、数据库服务器:数据库服务器是三层架构的最后一层,它是全部
信息源的中心,它负责存储、管理和维护系统各种信息,如文件、数据等。

从性能方面来看,这一层是最重要的,因为它负责处理最多的数据,而且
这些数据经过其他层处理后,最后都要以其中一种形式存储在数据库服务
器上。

三层架构-------理论篇

三层架构-------理论篇

三层架构-------理论篇概念:通常意义上的三层架构就是将整个业务应⽤划分为:表现层(UI)、业务逻辑层(BLL)、数据訪问层(DAL)。

区分层次的⽬的即为了“⾼内聚。

低耦合”的思想。

各层概念1、表现层(UI):通俗讲就是展现给⽤户的界⾯。

即⽤户在使⽤⼀个系统的时候他的所见所得。

2、业务逻辑层(BLL):针对详细问题的操作,也能够说是对数据层的操作,对数据业务逻辑处理。

3、数据訪问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、改动、查找等。

注:应⽤三层离不开还有⼀个重要的类:实体类,如今接触的主要是数据库表抽象出的类,表中的每⼀个字段就是⼀个详细实例。

相同跟业务实体相关的事物都能够成为实体类。

各层的作⽤1、数据訪问层:从数据源载⼊数据(Select)。

向数据源写⼊数据(Insert/Update);从数据源删除数据(Delete).是对数据的操作。

⽽不是数据库。

详细为业务逻辑层或表⽰层提供数据服务,不包括不论什么与业务相关的逻辑处理。

2、业务逻辑层:从DAL中获取数据,以供UI显⽰⽤;从UI获取⽤户指令和数据,运⾏业务逻辑。

从UI中获取⽤户指令和数据,通过DAL写⼊数据源。

对数据层的操作。

对数据业务逻辑处理。

职责机制:UI->BLL->UI;UI->BLL->DAL->BLL->UI3、表⽰层:从向⽤户展现特定业务数据;採集⽤户的输⼊信息和操作。

主要表⽰WEB⽅式和WINFROM⽅式。

原则:⽤户⾄上,兼顾简洁。

4、实体类:对于表⽰层来说,界⾯通过实体类传递数据。

将解析实体对象中封装的数据展⽰给⽤户;将⽤户请求的数据封装到实体对象中。

对于业务逻辑层来说,将接受到的实体对象传递到下⼀层;依据⽤户请求对实体中数据进⾏处理。

对于数据訪问层来说,从数据库取得数据通过实体类返回。

三层关系图添加实体后的关系图优缺点长处开发者仅仅关注整个结构中的当中某⼀层;能够⾮常easy的⽤⼼的实现来替换原有层次的实现;能够减少层与层之间的依赖;有利于标准化;利于个曾逻辑的复⽤;结构更加的明⽩。

三层架构详细的介绍了三层架构

三层架构详细的介绍了三层架构

三层架构详细的介绍了三层架构
三层架构是当前计算机网络技术中一种常用的模型,它将整个网络系
统分成三个不同的层次:应用层、传输层和网络层。

三层架构的设计概念
是“分而治之”,即把整个网络的工作任务分解成若干个独立的层,每个
层对下面一层只有非常有限的了解,而且不用理会其他层的活动情况,只
负责和本层有直接关系的活动,从而使网络的复杂性降低,操作用户也更
加容易掌握。

下面将详细介绍三层架构的每一层内容。

(一)应用层
应用层是计算机网络中最高的一层,它的主要功能是负责为用户提供
服务,为用户实现与网络的交互和通信,并且能够完成数据传输的功能。

应用层的技术包括:FTP(文件传输协议)、SMTP(简单邮件传输协议)、HTTP(超文本传输协议)、TELNET(网络终端协议)、SNMP(简单网络管
理协议)等协议,都是在应用层完成其功能。

(二)传输层
传输层是一个中间层,它的主要功能是完成数据的传输、控制和检验
操作,并且能够在发送端和接收端之间建立可靠的数据传输链路。

网络三层架构(修正)

网络三层架构(修正)
20XX
网络三层架构
2024/7/4
-
核心层 分布层 接入层
2
网络三层架构
网络三层架构是一种常见的网络设计模式,它将网络 划分为三个主要层次:核心层、汇聚层和接入层
x
每个层次都有其特定的功能和职责,使得网络设计更 加清晰和有效
Part 1
核心层
核心层
核心层是网络的最顶层,负责高速数据传输和主要网络流量的路由。它连接着各个汇 聚层设备,提供高速数据传输路径,并负责将数据流量从一个区域传输到另一个区域 。核心层设备通常为高性能路由器或交换机,具有高吞吐量、低延迟和高度冗余的特 点 在核心层,路由器和交换机之间的连接通常采用光纤或高速铜缆,以确保高带宽和低延迟 的数据传输。此外,核心层还应具备较高的容错性和可扩展性,以便在增加新设备或扩展 网络时能够保持性能和稳定性
02 提供较低的成本和灵活的网络连 接方式:以满足不同用户的需求
03 提供用户管理和安全控制功能:确 保网络的稳定性和安全性
12
接入层
总结:网络三层架构将 网络划分为核心层、分 布层和接入层三个层次 ,每个层次都有其特定 的职责和功能
这种架构有助于实现清 晰的网络设计和高效的 流量管理,提高网络的 性能和可靠性
04
提供高可靠性和稳定性:确保 数据的可靠传输和网络的稳定

03
提供较高的带宽和处理能力: 以支持大量数据流量的处理
Part 3
接入层
接入层
接入层是网络的底层,负责将用户设备(如计算机、服务器、打印机等)连接到网络。它为 用户设备提供网络连接和数据传输服务,并负责管理用户的访问和身份验证。接入层设备 通常为交换机、路由器或无线接入点(AP),具有较低的成本和较低的性能要求

三层架构的理解范文

三层架构的理解范文

三层架构的理解范文三层架构是指在软件系统开发过程中将系统划分为三个层次,每个层次有不同的功能和责任。

它是一种常用的架构设计模式,用于实现软件系统的可维护性、可扩展性和可重用性,具有很高的灵活性和可靠性。

三层架构由以下三个层次组成:表示层(或用户界面层)、业务逻辑层和数据访问层。

下面将逐层进行详细介绍。

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层架构就介绍到这里,关于抽象工厂,稍晚时候将做介绍,谢谢~。

三层架构

三层架构

三层架构----数据层(DAL)、逻辑层(BLL)、表示层(UI)1.什么是三层架构所谓的三层开发就是将系统的整个业务应用划分为表示层——业务逻辑层——数据访问层,这样有利于系统的开发、维护、部署和扩展。

分层是为了实现“高内聚、低耦合”。

采用“分而治之”的思想,把问题划分开来各个解决,易于控制,易于延展,易于分配资源。

·表示层:负责直接跟用户进行交互,一般也就是指系统的界面,用于数据录入,数据显示等。

意味着只做与外观显示相关的工作,不属于他的工作不用做。

·业务逻辑层:用于做一些有效性验证的工作,以更好地保证程序运行的健壮性。

如完成数据添加、修改和查询业务等;不允许指定的文本框中输入空字符串,数据格式是否正确及数据类型验证;用户的权限的合法性判断等等,通过以上的诸多判断以决定是否将操作继续向后传递,尽量保证程序的正常运行。

·数据访问层:顾名思义,就是用于专门跟数据库进行交互。

执行数据的添加、删除、修改和显示等。

需要强调的是,所有的数据对象只在这一层被引用,如System.Data.SqlClient 等,除数据层之外的任何地方都不应该出现这样的引用。

可以使用.NET平台快速方便地部署三层架构。

革命性的变化是在网页中也使用基于事件的处理,可以指定处理的后台代码文件,可以使用C#、VB、C++和J#作为后台代码的语言。

. NET中可以方便的实现组件的装配,后台代码通过命名空间可以方便的使用自己定义的组件。

显示层放在ASPX页面中,数据库操作和逻辑层用组件或封装类来实现,这样就很方便的实现了三层架构。

2.为什么使用三层架构对于一个简单的应用程序来说,代码量不是很多的情况下,一层结构或二层结构开发完全够用,没有必要将其复杂化,如果对一个复杂的大型系统,设计为一层结构或二层结构开发,那么这样的设计存在很严重缺陷。

下面会具体介绍,分层开发其实是为大型系统服务的。

在开发过程中,初级程序人员出现相似的功能经常复制代码,那么同样的代码为什么要写那么多次?不但使程序变得冗长,更不利于维护,一个小小的修改或许会涉及很多页面,经常导致异常的产生使程序不能正常运行。

三层架构简易实例详解 -回复

三层架构简易实例详解 -回复

三层架构简易实例详解-回复什么是三层架构?三层架构是一种常见的软件架构模式,将应用程序划分为三个主要的逻辑层:表示层(UI层)、业务逻辑层(BLL层)和数据访问层(DAL层)。

这种架构模式将不同的功能和职责进行了分离,使得应用程序更易于维护、拓展和重用。

表示层(UI层):表示层是用户与系统之间的接口,负责接收用户输入并向用户展示结果。

它通常包括用户界面、控制器和视图等。

用户界面负责与用户的交互,接收用户输入;控制器负责处理用户请求,将其传递给业务逻辑层;视图负责向用户展示处理结果。

业务逻辑层(BLL层):业务逻辑层是应用程序的核心,负责处理应用程序的业务逻辑。

它包含了应用程序的主要处理逻辑、算法和规则等。

业务逻辑层负责接收来自表示层的用户请求,进行处理并将结果返回给表示层。

数据访问层(DAL层):数据访问层是与数据存储和数据库交互的层。

它主要负责将业务逻辑层的请求转化为对数据库的操作,并将数据库返回的结果返回给业务逻辑层。

数据访问层的主要目的是将业务逻辑层与具体的数据存储实现进行解耦,使得业务逻辑层的实现与数据访问细节无关。

三层架构的优势:1. 模块化和可维护性:三层架构将应用程序拆分为不同的逻辑层,使得每个层次都具备清晰的功能和职责。

这种模块化的设计使得代码更易于维护和拓展。

2. 可重用性:由于不同的层次之间的耦合度较低,有助于提高代码的可重用性。

例如,业务逻辑层可以被多个不同的表示层共享,减少了重复编写代码的工作量。

3. 性能优化:三层架构可以根据实际需求进行负载均衡和性能优化。

例如,可以将数据库部署在单独的服务器上,以提高数据访问的效率。

4. 安全性:通过将业务逻辑与数据访问逻辑分离,可以更好地保护数据安全和业务逻辑的完整性。

5. 易于团队合作开发:每个层次的功能和职责被清晰划分,有助于团队合作开发。

不同的开发人员可以并行地开发不同的层次,减少了沟通和协作的压力。

三层架构的实例:假设我们要开发一个简单的学生管理系统,其中包括学生信息的录入、查询和删除等功能。

三丛集架构工作原理

三丛集架构工作原理

三丛集架构工作原理三层集架构是一种常见的软件架构模式,它将应用程序分为三个主要的层次:表示层、业务逻辑层和数据访问层。

每个层次都有其特定的功能和职责,通过这种架构模式可以实现系统的模块化、可维护性和可扩展性。

本文将详细介绍三层集架构的工作原理。

一、表示层表示层是用户与系统交互的接口,负责接收用户的输入,并将处理结果展示给用户。

它主要包括用户界面和用户交互逻辑。

用户界面可以是图形界面、命令行界面或者Web界面等,通过与用户进行交互获取用户输入的数据。

用户交互逻辑负责处理用户的输入,对输入进行验证和处理,并将处理结果传递给业务逻辑层。

表示层应该尽可能地简单和直观,使用户可以方便地使用系统。

二、业务逻辑层业务逻辑层是整个系统的核心,负责处理系统的业务逻辑和业务规则。

它接收来自表示层的数据,并进行相应的处理和计算。

业务逻辑层可以包括多个模块,每个模块负责处理特定的业务功能。

模块之间可以进行数据的交互和信息的传递,以完成复杂的业务操作。

业务逻辑层应该是独立于具体实现技术的,它只关注业务逻辑的处理,不涉及具体的数据存储和表示方式。

三、数据访问层数据访问层负责与数据存储进行交互,实现数据的读取和写入操作。

它可以访问各种类型的数据存储,如关系型数据库、文件系统或者其他的数据存储方式。

数据访问层封装了对数据存储的具体操作,提供了一组统一的接口供业务逻辑层进行数据的读取和写入。

通过数据访问层,业务逻辑层可以与具体的数据存储技术解耦,提高了系统的灵活性和可扩展性。

三层集架构的工作原理如下:用户通过表示层与系统进行交互,将输入的数据传递给业务逻辑层。

业务逻辑层根据业务规则对数据进行处理,并调用数据访问层进行数据的读取和写入操作。

数据访问层与具体的数据存储进行交互,将数据存储到数据库或者从数据库中读取数据。

最后,业务逻辑层将处理结果返回给表示层,表示层将结果展示给用户。

三层集架构的优点在于各个层次职责明确,模块化程度高,易于维护和扩展。

我的架构经验小结--深入三层架构

我的架构经验小结--深入三层架构

我的架构经验小结(三)--深入三层架构在我的架构经验小结(二)--关于三层架构一文中,已经比较深入的介绍过三层架构方面的一些经验了,现在,我们来使用一个更小的比例尺来近距离观察我所理解的三层架构。

一.三层架构图二.系统各层次职责1.UI(User Interface)层的职责是数据的展现和采集,数据采集的结果通常以Entity object 提交给BL层处理。

Service Interface侧层用于将业务或数据资源发布为服务(如WebServices)。

2.BL(Business Logic)层的职责是按预定的业务逻辑处理UI层提交的请求。

(1)Business Function 子层负责基本业务功能的实现。

(2)Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流。

(Transaction只能在Business Flow 子层开启。

)3.ResourceAccess层的职责是提供全面的资源访问功能支持,并向上层屏蔽资源的来源。

(1)BEM(Business Entity Manager)子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。

(2)DataAccess子层负责从数据库中存取资源,并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。

DB Adapter子层负责屏蔽数据库类型的差异。

ORM子层负责提供对象-关系映射的功能。

Relation子层提供ORM无法完成的基于关系(Relation)的数据访问功能。

(3)ServiceAccess子层用于以SOA的方式从外部系统获取资源。

注:Service Entrance用于简化对Service的访问,它相当于Service的代理,客户直接使用Service Entrance就可以访问系统发布的服务。

Service Entrance为特定的平台(如Java、.Net)提供强类型的接口,内部可能隐藏了复杂的参数类型转换。

三层架构原理

三层架构原理

三层架构原理今天来聊聊三层架构原理。

你知道盖房子吧?这和三层架构原理有点像呢。

咱们平常住的房子啊,大概能分成三层,地基一层、中间的楼层一层,还有楼顶那一层。

这每一层啊,都有自己的任务,组合在一起,房子才能稳稳当当的。

这三层架构呢,也是这么个道理。

先来说说最底下那层,叫数据访问层,就好比房子的地基。

这一层主要负责和数据库打交道,像我们存到数据库里的各种信息,用户的资料啊,商品的信息之类的,这一层负责把这些数据找出来或者存进去。

比如说,一家超市里,这个数据访问层就像仓库管理员,知道东西放在哪里,能拿出来,也能放回去。

我最开始理解这一层可费了好大劲儿呢,总是搞混它和其他层的功能。

中间那层是业务逻辑层,这个就像房子中间的楼层,是处理各种事务的核心。

在超市里,这一层就相当于收银员、理货员。

比如顾客来买东西,有打折怎么算啊,库存不够怎么处理啊,这些复杂的事儿都是这一层来决定的。

打个比方,你去商场买衣服,看到衣服在做活动,买一送一。

这个计算的过程就是业务逻辑层干的事,它根据设定的规则,算出你最终要花多少钱,商家又要做哪些内部的调整。

最上面的那层呢,是表示层,就像是房子的楼顶,是直接和用户打交道的。

这一层就是咱们看到的网页页面、软件的界面啥的。

还说超市,那货架怎么摆放好看,引导牌怎么立,让顾客能轻松找到想买的东西,就是表示层的事儿。

说到这里,你可能会问,为啥要搞这么个三层的架构呢?其实就像房子分层盖,有了明确的分工,修改或者扩展的时候就轻松多啦。

比如说我们想给超市添加一个新的会员制度,只要在业务逻辑层和数据库访问层添加对应的功能就行,页面那块儿不用动太多。

在实际应用中,假设开发一个电商网站。

如果没有分层,那代码就会乱得像一团麻。

以后想要增加新功能、修改旧功能的时候,找起来都困难。

分层之后,哪里出问题就能专门针对哪一层去修复。

老实说,有些复杂的业务场景下,怎么清晰划分三层间的界限,我还有点困惑呢。

不过通过不断的学习和实践,我发现,理解和运用三层架构原理,关键在于抓住每一层主要负责的事。

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

三层架构(我的理解及详细分析)
三层架构已经学了一段时间,一直想做一个比较完整、比较完美的总结。

但是左思右想,不知道如何下笔。

都说万事开头难嘛,今天整理了一下凌乱的思路,哎,还是没整理好,想到哪就说到哪吧。

初学者很不理解:
1,什么是三层?
2,为什么使用三层?
3,三层与以往使用的两层相比有什么不同?它的优势在哪里?
4,如何学好三层?如何应用三层?
……
这篇博客里我会给大家一一解释一下,略懂皮毛忘大家见谅!!!
米老师一直强调:让学习和生活结合,把学习和生活联系,这样的学习才叫会学习,会生活。

对于三层我左思右想,如何与实际相联系。

好嘛,昨晚突然有了“灵感”。

还记得大话设计模式里第23章大鸟和小菜吃羊肉串的故事——由在小摊吃到饭店吃引来的一个命令模式(当然今天不是研究命令模式)。

服务员、厨师、采购员。

这不就是个典型的三层架构吗???(⊙ o
⊙ )啊!哈哈(这个后面再做解释)
先了解:
1,什么是三层?
UI(表现层):主要是指与用户交互的界面。

用于接收用户输入的数据和显示处理后用户需要的数据。

BLL:(业务逻辑层):UI层和DAL层之间的桥梁。

实现业务逻辑。

业务逻辑具体包含:验证、计算、业务规则等等。

DAL:(数据访问层):与数据库打交道。

主要实现对数据的增、删、改、查。

将存储在数据库中的数据提交给业务层,同时将业务层处理的数据保存到数据库。

(当然这些操作都是基于UI层的。

用户的需求反映给界面(UI),UI反映给BLL,BLL反映给DAL,DAL进行数据的操作,操作后再一一返回,直到将用户所需数据反馈给用户)
每一层都各负其责,那么该如何将三层联系起来呢?
1&gt;单项引用(见下图)
2&gt;这时候实体层(Entity)来了。

(注:当然,实体层的作用不止这些)
Entity(实体层):它不属于三层中的任何一层,但是它是必不可少的一层。

Entity在三层架构中的作用:
1,实现面向对象思想中的"封装";
2,贯穿于三层,在三层之间传递数据;
(注:确切的说实体层贯穿于三层之间,来连接三层)
3,对于初学者来说,可以这样理解:每张数据表对应一个实体,即每个数据表中的字段对应实体中的属性(注:当然,事实上不是这样。

为什么?1>,可能我们需要的实体在数据表对应的实体中并不存在;2>,我们完全可以将所有数据表中的所有字段都放在一个实体里)
4,每一层(UI—&gt;BLL—&gt;DAL)之间的数据传递(单向)是靠变量或实体作为参数来传递的,这样就构造了三层之间的联系,完成了功能的实现。

但是对于大量的数据来说,用变量做参数有些复杂,因为参数量太多,容易搞混。

比如:我要把员工信息传递到下层,信息包括:员工号、姓名、年龄、性别、工资....用变量
做参数的话,那么我们的方法中的参数就会很多,极有可能在使用时,将参数匹配搞混。

这时候,如果用实体做参数,就会很方便,不用考虑参数匹配的问题,用到实体中哪个属性拿来直接用就可以,很方便。

这样做也提高了效率。

(注:这里为什么说可以暂时理解为每个数据表对应一个实体??答:大家都知道,我们做系统的目的,是为用户提供服务,用户可不关心你的系统后台是怎么工作的,用户只关心软件是不是好用,界面是不是符合自己心意。

用户在界面上轻松的增、删、改、查,那么数据库中也要有相应的增、删、改、查,而增删改查具体操作对象就是数据库中的数据,说白了就是表中的字段。

所以,将每个数据表作为一个实体类,实体类封装的属性对应到表中的字段,这样的话,实体在贯穿于三层之间时,就可以实现增删改查数据了)
综上所述:三层及实体层之间的依赖关系:
思想来源于生活:
服务员:只管接待客人;
厨师:只管做客人点的菜;
采购员:只管按客人点菜的要求采购食材;
他们各负其职,服务员不用了解厨师如何做菜,不用了解采购员如何采购食材;厨师不用知道服务员接待了哪位客人,不用知道采购员如何采购食材;同样,采购员不用知道服务员接待了哪位客人,不用知道厨师如何做菜。

他们三者是如何联系的?
比如:厨师会做:炒茄子、炒鸡蛋、炒面——此时构建三个方法(cookEggplant()、cookEgg()、cookNoodle())
顾客直接和服务员打交道,顾客和服务员(UI层)说:我要一个炒茄子,而服务员不负责炒茄子,她就把请求往上递交,传递给厨师(BLL层),厨师需要茄子,就把请求往上递交,传递给采购员(DAL层),采购员从仓库里取来茄子传回给厨师,厨师响应cookEggplant()方法,做好炒茄子后,又传回给服务员,服务员把茄子呈现给顾客。

这样就完成了一个完整的操作。

在此过程中,茄子作为参数在三层中传递,如果顾客点炒鸡
蛋,则鸡蛋作为参数(这是变量做参数)。

如果,用户增加
需求,我们还得在方法中添加参数,一个方法添加一个,一个方法设计到三层;何况实际中并不止设计到一个方法的更改。

所以,为了解决这个问题,我们可以把茄子、鸡蛋、面条作为属性定义到顾客实体中,一旦顾客增加了炒鸡蛋需求,直接把鸡蛋属性拿出来用即可,不用再去考虑去每层的方法中添加参数了,更不用考虑参数的匹配问题。

这样讲,不知道大家是不是可以明白。

(待会实例解释吧)
2,为什么使用三层?
使用三层架构的目的:解耦!!!
同样拿上面饭店的例子来讲:
(1)服务员(UI层)请假——另找服务员;厨师(BLL层)辞职——招聘另一个厨师;采购员(DAL)辞职——招聘另一个采购员;
(2)顾客反映:1&gt;你们店服务态度不好——服务员的问题。

开除服务员;
2&gt;你们店菜里有虫子——厨师的问题。

换厨师;
任何一层发生变化都不会影响到另外一层!!!
3,与两层的区别??
两层:
(当任何一个地方发生变化时,都需要重新开发整个系统。

“多层”放在一层,分工不明确耦合度高——难以适应需求变化,可维护性低、可扩展性低)
三层:
(发生在哪一层的变化,只需更改该层,不需要更改整个系统。

层次清晰,分工明确,每层之间耦合度低——提高了效率,适应需求变化,可维护性高,可扩展性高)
综上:三层架构的
优势:1,结构清晰、耦合度低,2,可维护性高,可扩展性高;3,利于开发任务同步进行;容易适应需求变化
劣势:1、降低了系统的性能。

这是不言而喻的。

如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相
应的数据,如今却必须通过中间层来完成。

2、有时会导致级联的修改。

这种修改尤其体现在自上而下的方向。

如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码
3、增加了代码量,增加了工作量
4,三层的具体表现形式??
UI:
(大家不要误会,UI层不只是一个个用户界面,也是需要有代码的)
(1,功能:用户输入数据、反馈给用户数据;2,大家观察代码:没有涉及到业务逻辑,直接传参、函数、方法调用,没有涉及到与数据库打交道的SQL语句和)
BLL:
(1,BLL是表示层与数据访问层之间的桥梁,负责数据处理、传递;2,大家观察代码,没有涉及到界面上的控件,没有涉及到SQL语句和)
DAL:
(1,以上是DAL层中DbUtil类、user_DA类和workRecord_DA类中的代码;2,大家观察代码,没有涉及到界面控件,没有涉及到业务逻辑;只有与数据库打交道的SQL语句和)
Entity(Model)层:
(定义了实体类user)
观察以上三层:
1,实体类user作为参数贯穿于三层之间;
2,通过传参、方法调用来实现功能;
3,各层之间各负其责;互不影响
对比两层结构,让大家深刻体会三层的极大好处:
还是以机房收费系统的登陆为例:
(观察上面的两层的代码:将业务逻辑、数据访问都展现在用户表现层,当需求需要改变时,需要改变整个系统。

比如,我把文本框txtPassWord的名称改为txtPwd的话,大家观察一下得需要更改多少地方。

这样的改动算是小的,如果真的有业务需求上的改动才叫麻烦复杂,程序员不跳楼才怪。

呵呵、、开个玩笑)
与如此难以适应需求变化的两层相比,大家再次观察三层代码,再次思考,三层架构有什么好处呢?自己思考。

自己去发掘吧!!!。

相关文档
最新文档