三层架构理论篇

对于三层架构的理论阐述,我将从三个大的方面去讨论:what、why和how,说白了也就是以三层架构为中心,去了解什么是三层,为什么用三层以及怎么用三层这个三个问题。OK,废话不多说,进入正题。

什么是三层架构?(What)

通常多层结构的划分方式有两种:分别是物理和逻辑。物理上的三层结构是指将整个应用系统分为显示层、业务层和数据层,并且这三个层面上的实体都是硬件,比如显示层就是客户机器,业务层通常是应用程序服务器,而数据层就是数据库服务器了。

今天我们讨论的主要是逻辑上的三层架构,是在软件设计时将软件的业务应用划分为:表现层(UI)、业务逻辑层(BLL)和数据访问层(DAL)。在软件体系架构中,分层式结构是最常见、也是最重要的一种结构。下面我们来看看这三层的具体含义和作用是什么。

表现层(UserInterface),还有一个概念叫做表示层(User Show Layer),无论叫什么吧,它们表达的意思基本上是一样的:一般来讲就是指展现给用户的界面,即用户在使用一个系统时的所见所得。这层的作用是向用户展现特定的业务数据,同时采集用户的输入信息和操作,主要表示为Web方式,也可以表示为Winform方式,位于系统的最上层,最接近用户,为用户提供了一种交互式操作的界面。

业务逻辑层(BusinessLogic Layer):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑进行处理。如果说数据层是各种蔬菜原材料,那么业务逻辑层就是做菜。同时业务逻辑层也是一座桥梁,负责连接UI和DAL,使它们能够很好的通信,从而完成系统的功能。它的作用有:从DAL中获取数据,以供UI显示用;从UI中获取用户指令和数据,执行业务逻辑;从UI中获取用户指令和数据,通过DAL写入数据库中。

数据访问层(DataAccess Layer):该层直接跟数据库打交道,主要操作就是对数据库进行增添、删除、修改和查找等。需要强调的一点是,数据访问层不是指存储原始数据的数据库,而是对数据的一些操作,具体为BLL或者UI提供数据服务。它的作用是:负责对数据库的访问,可以访问数据库系统,二进制文件,文本文档或者是XML文档。

至此我们已经了解了三层架构中每一层的含义和作用,但是仅仅有三层架构并不能让系统跑起来,因为层与层之间的通信问题是很复杂的,如果单靠参数传递进行通信那是非常麻烦的一件事情,因此我们要引入实体层,也就是数据模型,各层都引用数据模型,从而实现各层之间的数据传递和通信,说白了实体层就是一个数据结构体,里面是一些字段属性。

说了这么多,也许大家对三层架构还是没有一个形象的认识,笔者从网上找了一张不错的图,希望可以帮助大家更好的理解三层架构。

这张图很好的描述了各层之间的依赖关系,只是没有画出数据库(DB),那样的话就很容易让大家区分数据层和数据访问层这两个不同的的概念了。

为什么使用三层架构?(Why)

分层的目的是想将复杂问题简单化,也就是面向对象技术所崇尚的“高内聚,低耦合”。当一个项目过于复杂且涉及数据访问和存储的问题时,你就要考虑将整个业务应用进行分层,使用三层架构将业务简化,从而更好的设计和开发应用系统。

将一个大型项目分层有很多的优势:首先,开发人员只需要关注整个系统结构汇总的某一层即可,其他的不需要去考虑,并且这样可以很容易的实现系统的升级,只需要用新的实现替换原有层次的实现即可,其他的层次不用动,在后期的维护过程中,极大地降低了维护成本和时间;其次,可以大大的降低层与层之间的依赖,有利于封装各层的实现,便于各层逻辑的复用;最后,分层也有利于标准化,使系统的结构更加的明确。

当然,分层也有其自身的缺点:第一,分层降低了系统的性能,本来很多业务可以直接访问数据库,现在却要从中间层BLL绕一下,比较麻烦;第二,在某些情况下会导致连锁反应,比如你要在UI增加一个功能,为了保证分层结构,就要在相应的BLL和DAL中都加入相应的代码,麻烦;第三,增加了开发成本,这是显然的。

如何使用三层架构?(How)

三层架构的具体代码实现的例子,将在下篇博文中重点介绍,本次我们主要讨论在使用三层架构过程中要注意的一些原则或者说是规则。考虑一个项目是不是应该使用三层或者多层设计时,首先考虑是不是真的有必要?如何你的项目逻辑业务简单,甚至对数据库访问都没有,那完全没必要用三层架构啊。

即便是说你要使用三层架构,但不是说你把项目分成DAL、BLL和UI三个模块,就叫三层了,NO!在参考百度百科时,里面有几个问题值得思考

1.      UI里面只有少量(或者说没有)SQL语句或者存储过程调用,并且你能保证这些语句不会修改数据,越俎代庖?

2.      如果把你设计的UI拿掉,你的项目还能在Interface或者API的层次上提供所有功能吗?

3.      你的DAL可以移植到其他类似的环境的项目中接着运行吗?

4.      你所设计的三个模块,能否部署在不同的服务器上?

如果你的答案不都是YES,那么恭喜你:你的设计还不能算是严格意义上的三层结构。因为三层结构的程序需是有一些约定遵守的规则或者说是原则的:

DAL只提供基本的数据访问,不包含任何与业务相关的逻辑处理;

UI只负责显示和采集用户操作,不包含任何的业务相关的逻辑处理;

BLL负责处理业务逻辑,通过获取UI传来的操作指令,决定执行业务逻辑,在需要访问数据库的时候直接交给DAL处理,处理完成之后,返回必要的数据给UI。

还有一点值得注意的是,我们在做设计的时候一定要从BLL出发,而不要从UI出发,所有的业务逻辑都应该在BLL层实现,并且是以面向对象的方式实现。

至此,相信大家对三层架构有了一个基本的了解,当时要想在实际应用中灵活地去使用三层,还是比较困难的,需要我们不断的去思考,去实践,慢慢的摸索才能够将三层的优势发挥出来。

三层架构理论篇

时间: 2024-10-10 04:34:54

三层架构理论篇的相关文章

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

概念: 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI).业务逻辑层(BLL).数据访问层(DAL).区分层次的目的即为了"高内聚,低耦合"的思想. 各层概念 1.表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得. 2.业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理. 3.数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添.删除.修改.查找等. 注:应用三层离不开另一个重要的类:实体类,

三层学习------理论篇

学校放假了,刚回家的孩子就像个客人被父母招待着.在放假的前几天里,你尽管开口,想吃啥爸妈都会满足你,不过好景可不长!在我家,厨房是老妈的地盘,买菜.做饭.洗碗刷锅,一个人全包了.而在饭店吃饭呢,吃饭的人多了,顾客点的饭菜种类各不相同.前前后后,一个人忙乎,哪里顾得过来,所以饭店就有了分工.前台服务员负责将顾客点的菜上报给厨师和:厨师根据上报的菜单做菜:采购员负责柴米油盐酱醋茶.这样,大家各司其职,井井有条. 我们在家中吃饭比较简单,没有具体的分工.饭店就是一个复杂庞大的系统了,需要合理规划,分工

三层结构——理论篇

为什么要分层? 1.开发人员可以只关注整个结构中的其中某一层:2.可以很容易的用新的实现来替换原有层次的实现:3.可以降低层与层之间的依赖:4.有利于标准化:5.利于各层逻辑的复用.6..方便团队分工 分层: 将整个业务应用划分为:表现层(UI).业务逻辑层(BLL).数据访问层(DAL).区分层次的目的即为了"高内聚,低耦合"的思想. 1. 表现层 位于最外层(最上层),离用户最近.用于显示数据和接收用户输入的数据,为用户提供一种交互式操作的界面.它是系统的UI部分,负责使用者与整个

三层架构理论总结

What? 三层架构就是将整个业务应用划分为:表示层(Presentation Layer).业务逻辑层(Business Logic Layer).数据访问层(Data Access Layer). Why? 区分层次的目的是实现"高内聚,低耦合"的思想.三层结构是软件架构设计中,最普遍的一种结构. When? 当有数据访问以及业务逻辑的时候就要考虑使用三层结构了,此三层结构是按逻辑划分的.把数据访问脱离业务单独存在,把业务脱离开界面单独存在. 当数据逻辑简单,没有数据存储层,不需要

三层架构—简析

三层学习完了,第一次验收的时候,自己理解的也不是很到位,后来又重新敲了一遍登陆例子,查阅了一些资料 进行第二次验收才感觉清晰了许多.之前画时序图时我就想过时序图基本上也是很好的体现了三层,当时也和别人讨 论过这个问题.直到学完三层后,更加证明了这一点. 下面我将从理论和实践两个角度总结一下三层. 理论篇 为什么使用三层架构? 说白了,分层的目的是想将复杂问题简单化,也就是面向对象技术所崇尚的"高内聚,低耦合".当业务复杂到 一定程度,数据存储在独立的存储介质时适合用三层架构. 什么是三

从三层架构迈向领域驱动设计

本文读者基本要求:从事信息管理系统开发,略懂GOF设计模式及SOLID设计原则,对三层面向过程机械编码厌倦,并且不知道出路在何方,如果还掌握代码坏味和重构手法,那是极好的. 1. 三层架构 理论介绍-->实际经验-->总结反思 1.1 简单介绍三层架构 严格分层架构模式的特点是上层只能访问相邻的下层,其他层次间的调用都不允许.三层架构就是一种严格分层模式,它把职责划分为界面展示.业务逻辑.数据访问三层,还有一个业务实体,前面三层都要依赖它,所以它并不构成一个层.结构如图1. 三层架构的特点是一

【SSH2框架(理论篇)】--SSH2 Vs 经典三层

 这几天一直在学习使用SSH2框架.对于框架本身的使用并非非常困难.相信经过多锻炼就行熟练的掌握框架的使用,让我匪夷所思的是在使用框架的时候感觉非常熟悉,好像在哪里用过似得. 就在某次查看代码的时候突然闪现了一个想法,SSH2框架和经典三层非常相似.当然经过翻阅资料发现我的想法还是有理论根据的,接下来将会证实该猜想. 一.SSH2初识 我们通常所说的SSH2框架事实上是有三种框架集成的.它们各自是基于MVC模式的Struts2框架和基于IoC模式的 Spring框架以及对象/关系映射框架Hi

三层架构篇

QQ:1187362408 欢迎技术交流和学习 关于三层架构(ADO.NET): TODO: 1,页面表现层:统一调用BLL中的方法名称 2,业务逻辑层:依据业务需求,编写业务逻辑方法 3,数据访问层:对业务的每一项需求明细,编写数据处理方法 讲解篇: 1,页面表现层:只展现页面 2,业务逻辑层:只处理业务 3,数据访问层:只处理具体每一项业务数据

理论与实际相结合——三层架构解析

通常在程序编程中我们所说的三层架构是指:显示层(UI).逻辑层(BLL)和数据访问层(DAL).对于这三层来说,分工明确,各自有各自负责的领域. UI层:1.负责向用户显示数据  2.负责采集用户输入的信息 BLL层:1.从DAL获取数据,以供UI显示 2.从UI中获取指令或数据,经业务逻辑送达到DAL DAL层:1.主要用于对数据源的增删改查的操作. 通过它们各自负责的领域我们可以看出,BLL层属于中间层,它负责UI和DAL层之间的通信.那么通常我们还会加入一个实体层(Enity):主要负责返