业务层架构模式

一:业务层架构模式概述

在三层架构中,业务层负责所有业务相关的工作,包括根据输入数据或已有数据进行计算,对从表示层输入的数据进行验证,以及根据从表示层接收的命令来确定应该调用哪些数据访问逻辑。对于应用系统来说,业务层主要维护业务逻辑,是系统的核心部分。因此,在应用系统开发时,业务层的开发是最为关键的。

业务层的架构模式有多种,最著名的就是以下两种 :

事务脚本模型(面向过程的设计)

领域模型(面向对象的设计)

二:事务脚本模型

事务脚本(Transaction Script)架构模型是按照传统的过程化方式组织业务逻辑,它将业务层的业务逻辑组织为一系列的事务脚本,每个事务脚本是一个访问数据库并执行计算的方法,每个事务脚本处理来自于表示层的单个请求。事务脚本通常被分组在一起,形成一个事务脚本类,以实现一到多个用例的业务逻辑。

在使用事务脚本模式组织业务逻辑时,业务层结构由如下三个部分组成:

事务脚本:事务脚本类由一些方法组成,一个方法对应一个事务脚本,也就是对应一个用户请求。

DTO:事务脚本类操作DTO(Data Transfer Object,数据传输对象)。DTO只有成员变量,没有方法。它包含来自数据库的数据,并由事务脚本返回给表示层。//实体类

DAO:事务脚本使用DAO访问数据库

为了更清晰地理解事务脚本架构模式,我们以开发一个简单的员工管理系统为示例,今天的作业就是这个了!再增加一个根据条件查询信息的

开发基于事务脚本模式的业务逻辑的过程由四个步骤组成:

1)识别事务脚本;   识别事务脚本可以通过分析用例或者分析用户界面原型,其中分析用户界面原型最为直接简单。

2)实现事务脚本;   现在我们已经识别了事务脚本,并确定了它们的参数和返回值类型。那么,整个过程的下一步就是实现事务脚本接口。

3)实现DTO;   DTO在事务脚本和DAO之间,以及事务脚本和表示层之间传递。DAO使用DTO来返回需要从数据库获取的数据给事务脚本,事务脚本使用DTO传递数据到DAO,以更新数据库。事务脚本也会将DTO返回给表示层。

DTO只保存数据,只有成员变量和setter/getter方法。DTO及其成员变量可以组合如下三种识别技术来判断:

为每个数据库实体表定义一个DTO,DTO的成员变量与表的列对应。

为每个用户界面定义个DTO,DTO的成员变量包含显示在屏幕上的数据。

运用简单的OO分析和设计技术,识别类及其成员变量。

4)实现DAO。   每个DAO由一个接口和一个实现类组成。在上章我们已经学习过DAO的实现方法。这里不在详细讲述,只列出简单员工管理系统的DAO接口及实现类代码

事务脚本最大的优势在于使用简单。因为采用过程化设计,一个用户请求对应一个事务脚本,使用者无须拥有OO设计技能,不用识别类以及为类分配职责,任何初学者都可以很快掌握事务脚本模式来组织业务逻辑的方法。

缺点:因为事务脚本采用的是过程化设计的方法,所有业务逻辑都集中在事务脚本里面。很显然,将业务逻辑都集中在事务脚本里,违反了面向对象设计中单一职责等设计原则。这使得代码难以维护和理解,尤其是业务逻辑复杂的时候。

事务脚本模式虽然有缺点,但是至今仍然有很多开发团队采用该模式来组织业务层的业务逻辑。当业务逻辑相对比较简单时,采用事务脚本模式可以大大加快开发进度。同时,如果开发团队缺乏面向对象设计技能,采用事务脚本模式也是理智的选择。

时间: 2024-10-05 11:27:54

业务层架构模式的相关文章

面向对象——三层架构(表现层、业务层、持久层)

三层架构:即表现层.业务层.持久层. ① 持久层:采用DAO模式,建立实体类和数据库表映射(ORM映射).也就是哪个类对应哪个表,哪个属性对应哪个列.持久层 的目的就是,完成对象数据和关系数据的转换. ② 业务层:采用事务脚本模式.将一个业务中所有的操作封装成一个方法,同时保证方法中所有的数据库更新操作,即保证同时成 功或同时失败.避免部分成功部分失败引起的数据混乱操作. ③ 表现层:采用MVC模式. M称为模型,也就是实体类.用于数据的封装和数据的传输. V为视图,也就是GUI组件,用于数据的

Hibernate(1)——数据访问层的架构模式<转>

数据库的概念.逻辑.数据模型概念 应用程序的分层体系结构发展 MVC设计模式与四层结构的对应关系 持久层的设计目标 数据映射器架构模式 JDBC的缺点 Hibernate简介 迅速使用Hibernate开发的例子 Hibernate的核心类和接口,以及他们的关系 POJO和JavaBean的比较 之前的一篇总结文章: 数据库精华知识点总结(1)—数据库的三层模式和二级映像,E-R(实体联系图)图,关系模型 简单来说,就是在软件开发领域,可以用模型表示真实世界的实体.针对数据库就分为: 概念模型(

架构模式逻辑层模式之:表模块(Table Model)

表模块和领域模型比,有两个显著区别: 1:表模块中的类和数据库表基本一一对应,而领域模型则无此要求: 2:表模块中的类的对象处理表中的所有记录,而领域模型的一个对象代表表中的一行记录: 一般情况下,我们可以基于第二点来严格区分你的设计是表模块的,还是领域模型的.如:如果我们有许多订单,则领域模型的每一个订单都有一个对象,而表模块只有一个对象来处理所有订单(注意,这里的类,都是指业务逻辑层的类,而不是实体类.表模块的类的对象和常规的领域模型的对象很类似,但是关键区别是:它没有标识符来标出它所代表的

【转载】 JAVA三层架构,持久层,业务层,表现层的理解

JAVA三层架构,持久层,业务层,表现层的理解 转载:http://blog.csdn.net/ljf_study/article/details/64443653 SSH: Struts(表示层)+Spring(业务层)+Hibernate(持久层) Struts: Struts是一个表示层框架,主要作用是界面展示,接收请求,分发请求. 在MVC框架中,Struts属于VC层次,负责界面表现,负责MVC关系的分发. (View:沿用JSP,HTTP,Form,Tag,Resourse : Co

vb.net版机房收费系统——教你七层架构(三)—外观模式

上次我们看到了D层是怎样运作的,现在,我简单演示一下我的外观和B层是如何和U层和D层打交道的. 首先我跟大家说的是我的外观是按照界面功能划分的,粒度有点小,大家在做的时候,记得外观有几个就行了,但是不能没有,U层不能直接调用B层,这样就会增加U层和B层的耦合: '************************** '文 件 名:UserInfo_BLL '命名空间:BLL '内 容: '功 能: '文件关系: '作 者:邱慕夏 '小 组:邱慕夏 '生成日期:2014-06-07 17:36:4

标准架构~业务层到底是否应该关注数据持久化的方式

业务层,你不能知道数据库的实现细节 这个话题也是网上谈论的非常多的,你的业务层是否会包含你的数据层的相关架构技术,如,你的数据层的持久化通过EF来实现,那么你的业务层是否也应该引入EntityFrameworks程序集?占占还是会告诉你,不应该,因为这样会使你的业务不再是纯粹的业务,它会依赖由你的数据层的持久化实现的技术,这是不对的,我们需要把业务层解藕出来,只有这样,你的数据层在进行技术切换时,业务层才不会受到影响,当然,这是理所当然的,如果你的数据库换技术了,还会影响到你的业务层,那么,你这

架构模式: 根据业务能力拆分

架构模式: 根据业务能力拆分 上下文 您正在开发一个大型,复杂的应用程序,并希望使用微服务架构.微服务架构将应用程序构建为一组松散耦合的服务.微服务架构的目标是通过实现持续交付/部署来加速软件开发. 微服务架构以两种方式实现: 简化测试并使组件能够独立部署 将工程组织构建为小型(6-10个成员)自治团队的集合,每个团队负责一个或多个服务 这些好处不会自动得到保证.相反,它们只能通过将应用程序细致地功能分解为服务来实现. 服务必须小到足以由小团队开发并且易于测试.面向对象设计(OOD)的一个有用的

请问JAVA三层架构,持久层,业务层,表现层,都该怎么理解?和MVC三层模型有什么区别

持久层用来固化数据,如常说的DAO层,操作数据库将数据入库业务层用来实现整体的业务逻辑 如 前台获得了数据,逻辑层去解析这些数据,效验这些数据等操作表现层很好解释  你现在看到的网页 一些界面 都属于表现层的东西可以用一些Html,jsp,Swing来实现至于mvc么对应的是 model(模型) view(视图) Controller(控制)在javaweb中就很好理解了再XX系统中,前台页面属于view 贯穿前台后台持久层的一套模型就是model(EJB,Spring来实现)  而连接前台后台

CRM项目开发流程:采用《三层架构模式》

采用<三层架构模式> 1.根据顾客的需求设计数据表格,明确表之间的关联,建好约束 2.实体Bean的设计(一个表对应一个实体) 3.业务层设计(一个实体类一个业务接口,一次提交一个业务方法) 4.持久层设计(一个实体类一个持久接口,一次数据操作一个持久方法) 一.数据库表的建立: 建表时要注意表与表之间的联系,明确哪些是主键,哪些是外键,建立好约束. 要求数据添加合理,添加记录数量也要适当的多点,不然直接会影响后期持久层和业务层方法的调试,从而影响整个项目的开发. 表的列名要求命名规范,便于理