浅谈“三层架构”

今天我们来谈谈三层和传说中的“七层”。

三层:(先看图)

           

首先,我觉得学习三层并不太难,体现在三方面:认识不难、理解不难、它所展现的内容不难。

“认识三层”,网上随便一搜“软件的三层架构”云云,各种文章眼花缭乱。简单说三层就是指“表现层UI、业务逻辑层BLL和数据访问层DAL”。表现层主要处理用户与界面的关系,业务逻辑层当然是主要处理业务逻辑,数据访问层就是处理有关数据库的系列操作,比如增删改查等。

其次,理解三层不难。我们先说说它是怎么来的,为什么要用三层。

三层是从两层的基础上发展演变而来的,两层就是表现层和数据访问层,也就是没有BLL层的架构。在一些小的系统中,有时候我们确实不需要分三层,直接从界面传入数据,再通过操作数据库处理些简单的逻辑,最后返回结果给用户就OK了。但一些大型企业级软件,若是缺少了分层架构,将是灾难性的。

为什么这么说?我们可以很明显看出来,加入了BLL层后,业务逻辑有了自己的容身之地,不再和界面、数据有过多的联系了,也就是“解耦”了。无论是开发者还是维护者,最最不希望看到的就是系统里大把的耦合,耦合既不符合面向对象,也不符合软工的要求。就像是让你把十几种颜色不同的乱线头一一缕清,谁愿意干?

           “七层”:

除了解耦,三层架构还方便了代码重用。在这里,我们浅浅地说一下关于“七层”的故事。下面是一张“七层”图。

我在这里加了引号,是因为“七层”其实并不一定是七层,你甚至可以分为五层、六层、八层都行!七层只是一个象征性概念,就是三层加了一些设计模式的应用。上边这张图就是加了设计模式中的抽象工厂+反射、外观模式。

具体解释下,外观模式继续为UI层和BLL层解耦,使得UI层只需要调用Facade中的几个方法返回最后结果就行了,UI层最终与一切业务逻辑和数据处理无关;抽象工厂+反射+配置文件是用来方便数据库的,有了它,老板再也不担心你换数据库了!

具体实现过程中,你还可以分出sqlHelper类来放一些常用数据库操作过程,主要是那些重复性的,以减少DAL层代码量;另外,DBHelper也是个不错的选择,里边存放的是SQL Server/Oracle/OLEDB/ODBC等各类型数据库连接方式,方便数据库切换。

综上,我们说三层架构实现了代码重用。

           再回到三层:

           上面还说到三层展现的内容也不难。从上图我们可以看出,其实三层就是调用与实现的过程。

           下层并不需要上层的存在,它只需要完成自己的功能就万事大吉了。

比如UI层和BLL层,不论UI层长得什么样子,WinFrom也好、Web也罢,甚至不同的WinForm造型都无所谓,BLL层只需要处理好业务逻辑就行了,从UI层接收用户信息,最后再给出一个返回信息给UI层。

BLL层和DAL层也一样:DAL层从BLL层获得判断是否与UI层用户输入数据相同等指令(只是一个例子)进行数据处理,最后给BLL层一个值(对应为布尔值),BLL层对该值进行逻辑加工,再返回给UI界面,这个过程就结束了。

强调一下,三层之间并不是无联系,而是联系很弱。

关于三层的难点,我认为是三层在系统中的应用,怎样在三层架构下实现一个良好的类图结构,是当下需要考虑的重难点,随着笔者机房收费系统重构的进行,我们再做分析吧。

本文的不合理之处,还请各位读者提出宝贵意见。

浅谈“三层架构”

时间: 2024-10-03 14:45:15

浅谈“三层架构”的相关文章

浅谈三层架构(2)

感受: 对于三层的学习,自己刚开始的感觉真的是一头雾水啊,当时真的出现了很烦躁的感觉,我想这种感觉的出现真的是很可怕的,就这样耽误了两天,在网上也搜寻者自己想要的资料,昨天四姐也好心给调试了一番,顿时把自己的大脑打通了,其实问题难不难,就在于能不能打开思路了! VB.NET的三层实现: 上篇文章主要是对于三层有了一个表面的理解,下面针对机房收费登陆界面来进行一下简单的理解: UI层主要就是表面的构建,多以需要使用windows窗体来完成,而其他BLL和DAL则不需要,之间建立一个类库则可以完成自

浅谈三层架构(1)

这周单位要做一个人脸美化的项目,查资料遇到这位大牛的博客,地址如下:点击打开链接 我的代码也是在他的基础上进行修改的,但是他对图像的RGB三个通道平等调节,为了适应我的需求,我改成了针对三个通道分别调节.废话不多说,开始上源码 void ImageAdjust(Mat& src, Mat& dst, vector<double> low_in, vector<double> high_in, vector<double> low_out, vector&

浅谈三层架构

三层架构并不是MVC,MVC是一个很早就有的经典的程序设计模式,M-V-C分为三层,M(Model)-V(View)-C(Control).而web开发中的三层架构是指:数据访问层(DAL-DatabaseAccessLayer),业务逻辑层(BLL-BusinessLoginLayer),以及用户界面层(UI-UserInterface,实际就是网页后台的具体调用BLL层).这个是基本概念.曾经我以为三层架构就是在AppCode中,分为三个大类与若干小类,各司其职.在经过一番洗礼后,才发觉多么

浅谈三层模式

总觉的对三层的理解很肤浅,这几天看了相关的资料,无非谈的就是概括和基本组建附加个小例子!看完了,感觉说的大同小异,自己的理解好像也没什么多大变化,只不过加深了点罢了.不过想想有几天在这方面的思考,还是总结一下吧! 你去饭店吃饭,就遇见了三层,咱们唠唠吃饭这事! 服务员的作用就是给你上菜,收集你的信息,比如来个鱼香肉丝,或是几瓶啤酒,烤串什么的!总之你的一切请求都只是面向服务员的!至于厨师是男的,女的,负责给厨师买材料的采购员,你是没必要知道的.一切为了顾客,就是服务员的宗旨!等哪天这个服务员辞职

重构机房收费系统—浅谈三层

重构机房基本完成了,期间三层重构完了,推翻之后,再重构七层(外观和工厂),再重构,来来回回用了一个月........ 重构机房从画图画到一半就废弃了,因为对三层不熟,之后,做完了,才敢重新拾起来画.画图先从包图开始,宏观上有个了解: (一)重构机房包图: 先前画包图的时候,跟师傅交流,结果被一个师姐给笑话了,因为我认为:它们各个层之间都是双向箭头的,后来才知道,箭头表示调用关系,B层只能被U层或外观调用,B层不能调用U层,所以不存在双向箭头,大家注意. 在我这次重构中是严格按照上面的图中来的.

浅谈三层与实体

如果说类实现了封装,那么三层又将相关的类进行了封装,把它们封装在三个类库中.因为类的存在,减少了类与类之间的耦合:因为三层的存在,减少了职责不同的类之间的耦合. 所以三层的目的和面向对象的思想是一致的,就是要实现高内聚,低耦合,便于代码的更改,复用,即提高代码的灵活性,可维护性,复用性.还有一点很重要,就是安全. 我想看这篇文章的人至少对三层有一点点了解.一定知道三层包括:UI(User Interface Layer)表示层,BLL(Business Logic Layer)业务逻辑层,DAL

浅谈网站架构演变

浅谈网站架构 作为一个从事后台开发已经2年的程序员来讲,大部分时间都忙于业务逻辑分析,往往忽略了业务之上的架构层面的设计. 本文作为网站架构知识的补充,不仅开拓了眼界,也对以后的程序设计益处多多.下面我们就一起来看看网站架构的演变历史. 网站架构的演变大致分为如下几个阶段: 1 初始阶段的网站架构 网站在最初开始时没有太多人访问,用一台服务器就完全可以胜任,此时的网站架构如下图所示. 应用程序,文件存储,数据库所有的资源都在一台服务器上.也就是经典的LAMP架构模型(Linux操作系统+部署在A

浅谈android架构设计

到目前为止,android开发在网络上或者社区上没有公认的或者统一的开发框架,好多框架都是基于对方法的封装.今天在这浅谈两年来对android开发的理解,主要是思想上的理解,希望对大家有帮助. 我认为android开发可以从两个方面去总结架构的设计,在这里对于实现只做陈述: 一,就是大多数人的设计思路,对方法的封装. 在这里我根据开发的习惯对工程进行包的设计: 1. http:网络请求方法封装.这里建议采用线程+Handler的模式,把Http 中get方法和post两种请求方式分开,对于正常的

浅谈三层

三层大家都知道了,各种生活化的例子也就不再向大家举了.这里说说我对三层的理解. 三层: 所谓三层体系结构,是在客户端与数据库之间加入了一个"中间层",也叫组件层.这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上. 三层究竟有哪三层: 表现层(User Interface).业务逻辑层((Business Logic Layer).数据访问层((Data Access