软件的三层架构

全然看不懂

基于软件三层架构的研究报告

引言

三层结构是传统的客户/server结构的发展,代表了企业级应用的未来,典型的有Web下的应用。多层结构和三层结构的含义是一样的,仅仅是细节有所不同。之所以会有双层、三层这些提法,是由于应用程序要解决三个层面的问题。

一、  软件架构和分层

(一)  软件架构(software architecture)

是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描写叙述的对象是直接构成系统的抽象组件。各个组件之间的连接则明白和相对仔细地描写叙述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比方详细某个类或者对象。在面向对象领域中,组件之间的连接通经常使用接口(计算机科学)来实现。 软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员绘图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

(二)分层

分层是表示将功能进行有序的分组:应用程序专用功能位于上层,跨越应用程序领域的功能位于中层,而配置环境专用功能位于低层。分层从逻辑上将子系统划分成很多集合,而层间关系的形成要遵循一定的规则。通过分层,能够限制子系统间的依赖关系,使系统以更松散的方式耦合,从而更易于维护。子系统的分组标准包括下面几条规则可见度。各子系统仅仅能与同一层及其下一层的子系统存在依赖关系。

(三)使用分层架构开发的必要性

1、分层设计同意你切割功能进入不同区域。换句话说层在设计是就是逻辑组件的分组。比如,A层能够訪问B层,但B层不能訪问A 层。

2、用分层的方法,以提高应用程序的可维护性,并使其更easy扩展,以提高性能。

(四)设计分层的原则

1、层意味着组建的逻辑分组。比如,对用户界面,业务逻辑和数据訪问组建应该使用不同的不同的层。

2、在一个层内组建应该聚合的。如业务层组建仅应提供与业务逻辑相关的操作,而不是提供其它操作。

3、在设计的每个层接口时要考虑好物理边界。假设通信扩月了物理边界,使用基于消息操作;否则使用基于对象操作。

4、考虑使用接口类型(interface)来定义每层的接口。这将同意你创建该接口的不同实现,提高可測性。

5、对于Web应用程序,在表示层和业务逻辑层之间实现基于消息的接口是一个好主意,即使这两层没有跨越物理边界。基于消息的接口更适合于无状态的Web操作。

二、软件的三层架构

(一)概述

在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据訪问层、业务逻辑层(又或称为领域层)、表示层。

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

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

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

  

(二)三层结构原理:   

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

所谓三层体系结构,是在client与数据库之间增加了一个“中间层”,也叫组件层。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不唯独B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据訪问、合法性校验等工作放到了中间层进行处理。通常情况下,client不直接与数据库进行交互,而是通过COM/DCOM通讯与中间层建立连接,再经由中间层与数据库进行交互。

  

(三)各层的作用

数据訪问层:

有时候也称为是持久层,其功能主要是负责数据库的訪问,能够訪问数据库系统、二进制文件、文本文档或是XML文档。简单的说法就是实现对数据表的Select,Insert,Update,Delete的操作。假设要增加ORM的元素,那么就会包含对象和数据表之间的mapping,以及对象实体的持久化。主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据的操作,而不是数据库,详细为业务逻辑层或表示层提供数据服务。

  

业务逻辑层:

主要是针对详细的问题的操作,也能够理解成对数据层的操作,对数据业务逻辑处理,假设说数据层是积木,那逻辑层就是对这些积木的搭建。业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,非常多时候,也将业务逻辑层称为领域层。比如Martin Fowler在《Patternsof Enterprise Application Architecture》一书中,将整个架构分为三个基本的层:表示层、领域层和数据源层。作为领域驱动设计的先驱Eric
Evans,对业务逻辑层作了更仔细地划分,细分为应用层与领域层,通过分层进一步将领域逻辑与领域逻辑的解决方式分离。   业务逻辑层在体系架构中的位置非常关键,它处于数据訪问层与表示层中间,起到了数据交换中承上启下的作用。由于层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是“无知”的,改变上层的设计对于其调用的底层而言没有不论什么影响。假设在分层设计时,遵循了面向接口设计的思想,那么这样的向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下,理想的分层式架构,应该是一个支持可抽取、可替换的“抽屉”式架构。正由于如此,业务逻辑层的设计对于一个支持可扩展的架构尤为关键,由于它扮演了两个不同的角色。对于数据訪问层而言,它是调用者;对于表示层而言,它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上,怎样实现依赖关系的解耦,则是除了实现业务逻辑之外留给设计师的任务。
  

表示层:

位于最外层(最上层),离用户近期。用于显示数据和接收用户输入的数据,为用户提供一种交互式操作的界面。主要表示WEB方式,也能够表示成WINFORM方式,WEB方式也能够表现成:aspx, 假设逻辑层相当强大和完好,不管表现层怎样定义和更改,逻辑层都能完好地提供服务。

  

(四)详细调用

 

微软的DNA架构定义了三个层:表示层(presentation),业务逻辑层(business),和数据訪问层(data access)。详细又分为:界面外观层、界面规则层、业务接口层、业务逻辑层、实体层、数据訪问层、数据存储层共七层,其详细的调用如图1所看到的:

(五)规则

1.系统各层次及层内部子层次之间都不得跨层调用。

2.Entityobject 在各个层之间传递数据。

3.须要在UI层绑定到列表的数据採用基于关系的DataSet传递,除此之外,应该使用Entityobject传递数据。

4.对于每个数据库表(Table)都有一个DB Entity class与之相应,针对每个Entityclass都会有一个BEM Class与之相应。

5.有些跨数据库或跨表的操作(如复杂的联合查询)也须要由对应的BEM Class来提供支持。

6.对于相对简单的系统,能够考虑将Business Function子层和Business Flow 子层合并为一个。

7.UI层和BL层禁止出现不论什么SQL语句。

三、优缺点

(一)长处

1、开发者能够仅仅关注整个结构中的当中某一层;  

2、能够非常easy的用新的实现来替换原有层次的实现;  

3、能够减少层与层之间的依赖;   

4、有利于标准化;   

5、利于各层逻辑的复用。

(二)缺点

1、减少了系统的性能。这是不言而喻的。假设不採用分层式结构,非常多业务能够直接造訪数据库,以此获取对应的数据,现在却必须通过中间层来完毕。   

2、有时会导致级联的改动。这样的改动尤其体如今自上而下的方向。假设在表示层中须要添加一个功能,为保证其设计符合分层式结构,可能须要在对应的业务逻辑层和数据訪问层中都添加对应的代码。   

3、添加了开发成本。

(三)为什么要使用三层架构

对于一个简单的应用程序来说,代码量不是非常多的情况下,一层结构或二层结构开发全然够用,没有必要将其复杂化,假设对一个复杂的大型系统,设计为一层结构或二层结构开发,那么这种设计存在非常严重缺陷。以下会详细介绍,分层开发事实上是为大型系统服务的。在开发过程中,0基础程序人员出现相似的功能常常复制代码,那么相同的代码写那么多次,不但使程序变得冗长,更不利于维护,一个小小的改动也许会涉及非常多页面,常常导致异常的产生使程序不能正常执行。最基本的面向对象的思想没有得到丝毫的体现,打着面向对象的幌子却依旧走着面向过程的道路。意识到这种问题,0基础程序人员開始将程序中一些公用的处理程序写成公共方法,封装在类中,供其他程序调用。比如写一个数据操作类,对数据操作进行合理封装,在数据库操作过程中,仅仅要类中的对应方法(数据加入、改动、查询等)能够完毕特定的数据操作,这就是数据訪问层,不用每次操作数据库时都写那些反复性
的数据库操作代码。在新的应用开发中,数据訪问层能够直接拿来用。面向对象的三大特性之中的一个的封装性在这里得到了非常好的体现。如今找到了面向对象的感觉,代码量较曾经有了非常大的降低,并且改动的时候也比較方便,也实现了代码的重用性。

四、与MVC的差别

MVC是三个单词的缩写,分别为:模型(Model),视图(View)和控制Controller)。
MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑,通常能够用JavaBean或EJB来实现。
View层用于与用户的交互,通经常使用JSP来实现。 Controller层是Model与View之间沟通的桥梁,它能够分派用户的请求并选择恰当的视图以用于显示,同一时候它也能够解释用户的输入并将它们映射为模型层可运行的操作。

相同是架构级别的,相同的地方在于他们都有一个表现层,可是他们不同的地方在于其它的两个层。   

在三层架构中未定义Controller的概念。而MVC也没有把业务的逻辑訪问看成两个层,这是採用三层架构或MVC搭建程序最基本的差别。当然,在三层中也提到了Model,可是三层架构中Model的概念与MVC中Model的概念是不一样的,“三层”中典型的Model层是以实体类构成的,而MVC里,则是由业务逻辑与訪问数据组成的。

五、小结

在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。 所以,分层式设计能够达至例如以下目的:分散关注、松散耦合、逻辑复用、标准定义。一个好的分层式结构,能够使得开发者的分工更加明白。一旦定义好各层次之间的接口,负责不同逻辑设计的开发者就能够分散关注,齐头并进。尽管三层架构仍有不可避免的缺陷,可是软件分层结构使得代码维护很方便,设计明白,各层独立,专注自己擅长的领域。通过这次报告,对软件体系结构又有了更深入的了解。

时间: 2024-11-10 07:14:28

软件的三层架构的相关文章

有了门面,程序会更加体面!- pos软件基于三层架构 -09

续上篇)        大鸟说道:"实际上没有学过设计模式去理解三层架构会有失偏颇的,毕竟分层是更高一级别的模式,所谓的架构模式.不过在程序中,有意识的遵循设计原则,却也可以有效的做出好的设计."      "不要告诉我,刚才讲的'迪米特法则'就会在分层中用得上?"小菜说.     "当然用得上,否则讲它干吗,你当我是在安慰你而临时编个法则来骗骗你呀?来,再来看看你上次写的代码." 先来看看之前用反射机制改良的pos程序 DataSet ds;

软件开发三层架构模型学习

软件开发的三层架构: 三层架构的理解: 服务员--厨师--后勤工作人员(提供材料) UI表示层--BLL业务逻辑层--DAL数据访问层(每一层都有哪些知识点需要学习) UI表示层: 显示数据和接收用户输入 BLL业务逻辑层: 处理用户输入的信息: 或将信息发送给数据访问层进行保存: 或通过数据访问层从数据库读出这些数据. DAL数据访问层: 对数据的保存和读取操作 三层架构各层的职责分配(各司其职,不做多余工作) 表示层(UI):只接收用户输入的数据,并将业务逻辑层处理数据的结果显示给用户. 业

浅谈“三层架构”

今天我们来谈谈三层和传说中的"七层". 三层:(先看图)             首先,我觉得学习三层并不太难,体现在三方面:认识不难.理解不难.它所展现的内容不难. "认识三层",网上随便一搜"软件的三层架构"云云,各种文章眼花缭乱.简单说三层就是指"表现层UI.业务逻辑层BLL和数据访问层DAL".表现层主要处理用户与界面的关系,业务逻辑层当然是主要处理业务逻辑,数据访问层就是处理有关数据库的系列操作,比如增删改查等. 其

合作开发三层架构版机房中的一些工具软件

一,EA 关于EA的使用,以前在http://blog.csdn.net/lhc1105/article/details/38128513 .真心感觉不错. 二,动软代码生成器 这个小东西主要因为是中文的,用起来感觉比EA上手,可以进行一些简单的操作:比如: 1,为数据库自动生成常用存储过程,也可以将自动生成的存储过程导出,交给D层的开发人员复制粘贴使用,减少工作量. 2,导出数据库设计文档,不过这个文档有点儿简单,要自己完善下. 3,生成三层架构的主体代码: 如图,连带有工厂模式的代码都可以生

软件三层架构和MVC模式的区别

刚开始学习MVC模式的时候,很容易将两个混为一谈,觉得两者一个是中文描述,一个是英文描述(哈哈,很奇怪当时的想法),当深入了解后,发现根本不是一回事啊,遂将两者做一下总结: 1. 从概念上来说: 三层架构是一个分层式的软件体系架构设计,适用于任何一个项目.而MVC是一种设计模式,它是根据项目的具体需求来决定是否使用这个设计模式 .从一个项目开始,首先需要进行架构设计,一般采用分层式的架构设计,即三层架构.在确定了架构设计之后,会根据具体的需求去考虑是否需要应用设计模式,比如说MVC模式,抽象工厂

[转]从三层架构到MVC,MVP

本来是不想跳出来充大头蒜的,但最近发现园子里关于MVC的文章和讨论之风越刮越烈,其中有些朋友的观点并不是我所欣赏和推荐的,同时最近也在忙着给公司里的同事做MVC方面的“扫盲工作”.所以就搜集了一些大家接触MVC的过程中经常出现的问题做了一下解释说明,希望能与大家多多交流,呵呵. 当然这种架构模式本身的一些问题也会在接下来的内容就加以介绍,另外就是如果大家有什么不同观点的话,欢迎拍砖(只要不打脸就行,呵呵). 一.  MVC是谁提出的         模型-视图-控制器(MVC)是Xerox PA

从头开始做一个OA项目(三) 关于三层架构思想

下面就开始一步一步的搭建我们的项目三层架构,自从微软的PetShop推出以来,似乎它就成了三层的代名词.在国内.Net界几乎所有的项目都是根据PetShop来搭建三层架构,甚至我还见过一些项目直接就把它的架构拷贝过来,一丝未改.直接使用.在搭建之前,为了便于还未接触过三层的同学了解.我们先把三层架构的基本概念解释一下.我们先来思考一个场景.我们大家都去过饭店吃饭,那么大家回忆一下我们吃饭的流程是个什么样子呢?如下图所示. 当我们推开饭店的大门,马上就会迎来一个笑容可掬的服务员,她会忙着招待我们,

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

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

简析三层架构

三层架构--3-tier architecture 通过几个问题,来初步的学习一下三层架构. 1.什么是三层架构 2.应用场景--为什么要用三层架构? 3.三层作用 4.各个层之间的关系 5.三层联系--引用 6.各层是怎样调用的 7.三层和二层的对照 这几个都是学习三层中最主要的问题,仅仅有把这些问题搞清楚.才算是打开了三层的门. 1.什么是三层架构 在软件体系架构设计中,分层式结构是最常见.也是最重要的一种结构.三层从下至上分别为:数据訪问层(DAL).业务逻辑层(BLL).表示层(UI).