精华内容
下载资源
问答
  • 什么是业务逻辑层
    千次阅读
    2020-11-21 09:51:00

    业务逻辑层是专门处理软件业务需求的一层,处于数据库之上,服务层之下,完成一些列对Domain Object的CRUD,作为一组微服务提供给服务层来组织在暴露给表现层,如库存检查,用法合法性检查,订单创建。

    业务逻辑层包含领域对象模型,领域实体,业务规则,验证规则,业务流程

    1、领域对象模型为系统结构描述,包含实体功能描述,实体之间的关系。

    2、领域实体:业务层是一些操作业务对象(BO)的处理。业务对象包含数据和行为,是一个完整的业务对象。其不同于上节架构设计中服务层的数据迁移对象(dto),对于dto存在数据的,不存在行为,dto是bo(ddd中又称do)的子集,负责与特定界面需求的扁平化实体,dto仅仅是一个数据载体,需要跨越应用程序边界,而业务对象则不会存在复制迁移,往往一个业务对象存在一个或者多个数据迁移对象。

    3、业务最大的逻辑就在处理一些列现实世界的规则,这也是软件中最容易变化的部分,这里通常会出现我们众多的if-else或者switch-case的地方。也这因为如果说以个人觉得在我们的项目最应该关系和分离需求的层次。

    4、验证规则:业务规则很大程度上也是对对象的数据验证,验证业务对象的当前数据状态。我觉得在每个业务对象上都应该存在一个对外部对象暴露的验证接口,可以考虑微软企业库的VAB 基于Attribute声明式验证或者上节流畅的验证组件:FluentValidation中的FluentValidation验证组件基于IOC的解耦。

    业务层模式:在常见的业务层模式中主要分为过程是模式和面向对象模式。过程模式有是事务性脚本和表模式,而面向对象模式为活动记录模式和领域驱动模式。理论上说事务性脚本模式是最简单的开发模式,其前期投入下,但随着项目周期和复杂度上升明显,而领域模型(DDD)前期投入较大,但是理论上说是随着项目周期和复杂度呈线性增加,当然这些都是理论值。

    1、事务脚本模式是业务逻辑层最简单的模式,面向过程模式。该模式以用于的操作为起点,设计业务组件,即业务逻辑直接映射到用户界面的操作。这通常是从表现层逻辑出发,表现层我需要什么业务层提供什么,直到数据层。针对没一个用户的新功能都需要新增一个从UI到关系数据库的分支流程。其使用与逻辑不是很复杂或者变化不大稳定的应用系统开发。其不需要付出与业务无关的额外代价,并且在现代VS之类的IDE帮助下能够很快的进行快速应用开发(RAD)。也由于这种优势,也是其最大的劣势,程序中充满了IF-else,switch-case之类的逻辑或者大量的static的方法,每个功能都是一个程序分支,这对代码无法重用。编码不易于维护,对复杂项目和变化需求不适应。

    2、表模式:为每个数据库表定义一个表模块类,包含操作该数据的所有行为方法。作为一个容器,将数据和行为组织在一起。其对数据的粒度针对于数据表,而非数据行,因此需要以集合或者表传递数据信息。表模式基于对象但是完全又数据库驱动开发,在业务模型和数据库关系模型显著差异的情况下,应对需求,并不是那么适合。但是在.net中提供的一些列如强类型DataSet等IDE的辅助下自动生成大量的代码,也是一个不错的选择,因为部分数据库的操作趋于自动化。表模式没太过于关注业务,而是关注数据库表结构。而业务逻辑和领域问题才是软件核心。

    3、活动记录模式:一个以数据库表一行Row为对象,并且对象中包含行为和数据的模式方法。其数据对象很大程度的接近数据库表结构。在活动记录模式对象中通常也包含操作对象的CRUD行为,数据验证等业务规则。对于业务不是很复杂,对象关系与关系模型映射不具有很大差异情况,活动记录模式会运用的很好。活动模式比较简单化设计,在上现行的很多如Linq to sql,ActiveRecord框架的辅助下,将针对问题领域不是太过复杂的项目十分有用。但是其模式和数据库表结构的相互依赖,导致若你修改数据库结构,你不得不同时修改对象以及相关逻辑。如果不能保证数据库关系模型和对象模式的很大程度的相似这就进入的困境。

    4、领域模型:在前面的几种模式都是项目开始站在了以数据为中心的角度,而不是业务本身的问题领域。而领域模型关注系统问题领域,首先开始为领域对象设计。与活动记录模式来说,领域模型完全站在了问题领域业务概念模型一边,与数据库,持久化完成独立,其推崇持久化透明(POCO)。其可以充分利用面向对象设计,不受持久化机制的任何约束。其实完全又业务驱动出来的。但是其最大的优势如上各个模式一样也是其最大的劣势对象模型和关系模型具有天然的阻抗,我们的领域实体早晚需要映射到持久化机制。还好的是当前有NHibearnate,EF,Fluent NHibearnate这类ORM框架辅助。在DDD中包含UOW,仓储,值类型和聚合根,领域事件,领域跟踪一类的概念,这将在以后具体说明。

    模式的选择在于架构师的决定,这也是架构师具有挑战意义的职责,需要根据具体的项目需求,团队,个人等外界因素最终决定,不存在万能的模式,也不存在完美的设计。

    更多相关内容
  • 业务逻辑层是专门处理软件业务需求的一层,处于数据库之上,服务层之下,完成一些列对Domain Object的CRUD,作为一组微服务提供给服务层来组织在暴露给表现层,如库存检查,用法合法性检查,订单创建。  业务逻辑...

    转载地址:http://www.cnblogs.com/whitewolf/archive/2012/05/29/2524881.html

    业务逻辑层是专门处理软件业务需求的一层,处于数据库之上,服务层之下,完成一些列对Domain Object的CRUD,作为一组微服务提供给服务层来组织在暴露给表现层,如库存检查,用法合法性检查,订单创建。

       业务逻辑层包含领域对象模型,领域实体,业务规则,验证规则,业务流程。1:领域对象模型为系统结构描述,包含实体功能描述,实体之间的关系。领域模型处于天生的复杂性:2:领域实体:业务层是一些操作业务对象(BO)的处理。业务对象包含数据和行为,是一个完整的业务对象。其不同于上节架构设计中服务层的简单理解提到的数据迁移对象(dto),对于dto存在数据的,不存在行为,dto是bo(ddd中又称do)的子集,负责与特定界面需求的扁平化实体,dto仅仅是一个数据载体,需要跨越应用程序边界,而业务对象则不会存在复制迁移,往往一个业务对象存在一个或者多个数据迁移对象。3:业务最大的逻辑就在处理一些列现实世界的规则,这也是软件中最容易变化的部分,这里通常会出现我们众多的if-else或者switch-case的地方。也这因为如果说以个人觉得在我们的项目最应该关系和分离需求的层次。4:验证规则:业务规则很大程度上也是对对象的数据验证,验证业务对象的当前数据状态。我觉得在每个业务对象上都应该存在一个对外部对象暴露的验证接口,可以考虑微软企业库的VAB 基于Attribute声明式验证或者上节流畅的验证组件:FluentValidation中的FluentValidation验证组件基于IOC的解耦。

       业务层模式:在常见的业务层模式中主要分为过程是模式和面向对象模式。过程模式有是事务性脚本和表模式,而面向对象模式为活动记录模式和领域驱动模式。理论上说事务性脚本模式是最简单的开发模式,其前期投入下,但随着项目周期和复杂度上升明显,而领域模型(DDD)前期投入较大,但是理论上说是随着项目周期和复杂度呈线性增加,当然这些都是理论值。

      1:事务脚本模式是业务逻辑层最简单的模式,面向过程模式。该模式以用于的操作为起点,设计业务组件,即业务逻辑直接映射到用户界面的操作。这通常是从表现层逻辑出发,表现层我需要什么业务层提供什么,直到数据层。针对没一个用户的新功能都需要新增一个从UI到关系数据库的分支流程。其使用与逻辑不是很复杂或者变化不大稳定的应用系统开发。其不需要付出与业务无关的额外代价,并且在现代VS之类的IDE帮助下能够很快的进行快速应用开发(RAD)。也由于这种优势,也是其最大的劣势,程序中充满了IF-else,switch-case之类的逻辑或者大量的static的方法,每个功能都是一个程序分支,这对代码无法重用。编码不易于维护,对复杂项目和变化需求不适应。

      2:表模式:为每个数据库表定义一个表模块类,包含操作该数据的所有行为方法。作为一个容器,将数据和行为组织在一起。其对数据的粒度针对于数据表,而非数据行,因此需要以集合或者表传递数据信息。表模式基于对象但是完全又数据库驱动开发,在业务模型和数据库关系模型显著差异的情况下,应对需求,并不是那么适合。但是在.net中提供的一些列如强类型DataSet等IDE的辅助下自动生成大量的代码,也是一个不错的选择,因为部分数据库的操作趋于自动化。表模式没太过于关注业务,而是关注数据库表结构。而业务逻辑和领域问题才是软件核心。

      3:活动记录模式:一个以数据库表一行Row为对象,并且对象中包含行为和数据的模式方法。其数据对象很大程度的接近数据库表结构。在活动记录模式对象中通常也包含操作对象的CRUD行为,数据验证等业务规则。对于业务不是很复杂,对象关系与关系模型映射不具有很大差异情况,活动记录模式会运用的很好。活动模式比较简单化设计,在上现行的很多如Linq to sql,ActiveRecord框架的辅助下,将针对问题领域不是太过复杂的项目十分有用。但是其模式和数据库表结构的相互依赖,导致若你修改数据库结构,你不得不同时修改对象以及相关逻辑。如果不能保证数据库关系模型和对象模式的很大程度的相似这就进入的困境。

    4:领域模型:在前面的几种模式都是项目开始站在了以数据为中心的角度,而不是业务本身的问题领域。而领域模型关注系统问题领域,首先开始为领域对象设计。与活动记录模式来说,领域模型完全站在了问题领域业务概念模型一边,与数据库,持久化完成独立,其推崇持久化透明(POCO)。其可以充分利用面向对象设计,不受持久化机制的任何约束。其实完全又业务驱动出来的。但是其最大的优势如上各个模式一样也是其最大的劣势对象模型和关系模型具有天然的阻抗,我们的领域实体早晚需要映射到持久化机制。还好的是当前有NHibearnate,EF,Fluent NHibearnate这类ORM框架辅助。在DDD中包含UOW,仓储,值类型和聚合根,领域事件,领域跟踪一类的概念,这将在以后具体说明。

      模式的选择在与架构师的决定,这也是架构师具有挑战意义的职责,需要根据具体的项目需求,团队,个人等外界因素最终决定,不存在万能的模式,也不存在完美的设计。


    作者:破  狼 
    出处:http://www.cnblogs.com/whitewolf/ 
    本文版权归作者,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。该文章也同时发布在我的独立博客中-博客园--破狼51CTO--破狼


    展开全文
  • 什么是业务逻辑

    万次阅读 多人点赞 2018-09-04 20:32:07
    不同的项目有不同的功能,不同的功能需要不同的实现,实现这些核心功能的代码就叫业务逻辑 ...难题:什么是业务逻辑?   业务是指一个实体单元向另一个实体单元提供的服务。 逻辑是指根据已有的信...

    不同的项目有不同的功能,不同的功能需要不同的实现,实现这些核心功能的代码就叫业务逻辑
    比如让你实现一个功能,给你两个数,让你获取它的和,你所写的如何才能获得任意给定的两个数的和,这个程序实现过程即可成为业务逻辑处理。

     

     

     

    “一个人了解的业务逻辑越多越细,他就是越好的需求分析师。”

    难题:什么是业务逻辑
     

    业务是指一个实体单元向另一个实体单元提供的服务。
    逻辑是指根据已有的信息推出合理的结论的规律。


    业务逻辑是指一个实体单元为了向另一个实体单元提供服务,应该具备的规则与流程。

    就像你家的规矩–“吃饭前必须洗手”“有客人来要起立”“睡觉前各自说晚安”-就是业务逻辑的生活化实例。


    在软件系统架构中,软件一般分为三个层次:表示层、业务逻辑层和数据访问层:

    • 表示层:负责界面和交互;
    • 业务逻辑层:负责定义业务逻辑(规则、工作流、数据完整性等),接收来自表示层的数据请求,逻辑判断后,向数据访问层提交请求,并传递数据访问结果,业务逻辑层实际上是一个中间件,起着承上启下的重要作用;
    • 数据访问层:负责数据读取。

     

    业务逻辑的内容包括四个部分:

    • 领域实体:定义了业务中的对象,对象有属性和行为;
    • 业务规则:定义了需要完成一个动作,必须满足的条件;
    • 数据完整性:某些数据不可少;
    • 工作流:定义了领域实体之间的交互关系。

     

    以大毛网购裤子为例

    • 领域实体:大毛、资金账户、订单、裤子、发货单
    • 业务规则:大毛点击购买就会生成订单,但必须付了钱,才会发货,生成发货单。
    • 数据完整性:淘宝网下订单必须登录账号,没有账号就不能成功购买。
    • 工作流:搜索裤子-找到合意裤子-下单购买-付账-收货。

    业务逻辑:搜索“裤子”-找到合意裤子-下单-必须登录账号-结算-付账-收货。

    当当必须登录账号才能下单成功,亚马逊就不需要,今天发现淘宝也不需要登录账号就能购买商品了,所以每个网站的规则的不同,就形成了不同的业务逻辑,业务逻辑不仅仅包括规则,还包括实体、数据完整性、工作流。如图:

    业务逻辑图

     

    业务逻辑图

    业务逻辑也需要画图,叫做业务逻辑图,它跟业务流程图有什么区别呢?
    业务流(工作流)是业务逻辑的一部分,它定义了对象之间的交互关系,但不涉及到规则的制定,数据的完整性方面。
    其实,我们平常画的业务流程图多数是业务逻辑图。
     

     

    所谓的三层开发就是将系统的整个业务应用划分为表示层,业务逻辑层和数据访问层,这样有利于系统的开发、维护、部署和扩展

    分层是为了实现“高内聚,低耦合”。采用“分而治之”的思想,把问题划分开来各个解决,易于控制,延展

    和分配资源。

     

    所谓的三层开发就是将系统的整个业务应用划分为表示层,业务逻辑层和数据访问层,这样有利于系统的开发、维护、部署和扩展。

    分层是为了实现“高内聚,低耦合”。采用“分而治之”的思想,把问题划分开来各个解决,易于控制,延展和分配资源。

    业务逻辑层负责系统领域业务的处理,负责逻辑性数据的生成、处理及转换。对所输入的逻辑性数据的正确性及有效性负责,但对输出的逻辑性数 据及用户性数据的正确性不负责,对数据的呈现样式不负责。


    JavaEE三层架构MVC,把视图控制器模型分开来

    那么在这里业务逻辑就是M。

    但是什么样的算是业务逻辑如:上传一个文件,上传代码算是一个业务逻辑吗?

    数据库操作增加时需要判断,和一些其它这算业务逻辑吗?(我觉得算)

    但是hibernate又提供了一个离线查询对象(DetachedCriter),提供这个接口的意思我想是在外面处理业务逻辑。

    但是三层架构不是独立的吗?互相不干涉吗?在service层出现sql,hql,criter不是又把dao与service连在一起了吗?

    DTO(VO),POJO,BO这些是什么,POJO对应数据库,BO对应业务逻辑,DTO对应页面的传输与显示。

     


           业务逻辑就是处理数据的逻辑啦。一般后台代码也分三层 action(controller) service DAO (这里的三层不是MVC)

     

            比如 我得到用户名 但是在存入数据库的时候 用户名字段应该是前台的用户名加上当前日期拼成的字符串

    action或者controller层是第一层 一般是用来及接受数据并且做数据的非空啊 格式是否正确的验证

      如用户名是否为空 是不是安全字符串之类的

    service层一般是用来做一个业务逻辑的实现

      这时候 userName = userName + new Date();

     

           DAO层 就是与数据库交互层啦

      也就是读写数据库 将逻辑层得到的新的userName插入到数据库

     

          MVC和三层架构并没有可比性三层架构是指将程序分为数据访问、业务处理、界面三个层次,是软甲整体架构MVC是仅仅是界面架构,也就是它其实只是三层架构的界面部分,M是指实体模型或者实体模型的一个代理,而非领域模型,C是指控制器,仅仅是做转向,不应该包含任何业务逻辑,V就是视图了。至于那些个什么什么O,都是实体在不同层的映射。另外值得一提的是,MVC在一些小的程序中也经常被当做软件整体架构,那个时候M往往就是实体模型了,但是这种时候,V就对M产生了直接引用,也就是界面对实体产生依赖,这是很不好的(但小程序问题不大),此时可以尝试使用MVP模式解耦。至于业务,看你怎么定义领域模型了,一般像上传文件这种操作并不会牵扯企业的业务,那就不应该当做一个业务,但如果这个上传是在工作流或者一些特殊处理中,则有可能上升到业务。怎么做,要看具体问题。

    转自原文:https://blog.csdn.net/u010098331/article/details/51700777

    展开全文
  • 三层架构之业务逻辑层(BLL)

    千次阅读 2020-06-25 20:42:33
    一、BLL:针对具体问题的操作,也可以说是对数据的操作,对数据业务逻辑处理。 1、模板: windows->类库 2、引用: Model、DAL 3、原则:一个Service对应一个Manage类 4、实现:复制DAL、粘贴,到BLL,改为...

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

    1、模板: windows->类库
    2、 引用: Model、DAL
    3、原则:一个Service对应一个Manage类


    4、实现:复制DAL层、粘贴,到BLL 层,改为调用

    DAL层

    BLL层 

     

    把DAL层里的内容删除,然后return调用DAL层所编写的方法

    明天将会给大家讲述三层架构中最重要的UL层,可能内容会有点多,会分开讲解 

    展开全文
  • 三层架构之业务逻辑层

    千次阅读 2022-02-23 21:41:34
    今天我们讲一讲三层架构中的业务逻辑层 1、业务逻辑层的介绍 业务逻辑层(Business Logic Layer,简称BLL)是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关...
  • 什么是业务逻辑层

    千次阅读 2012-08-07 23:35:19
    抽象地说,业务逻辑层是软件中专门处理业务相关任务性能的部分。 业务层是所有分层系统的核心,包含了系统的核心逻辑。通常也叫作业务逻辑层
  • 三层架构(3-tier application)通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。1、表现层(UI):通俗讲就是展现给...
  • 所谓的三层开发就是将系统的整个业务应用划分为表示层——业务逻辑层——数据访问层,这样有利于系统的开发、维护、部署和扩展。 分层是为了实现“高内聚、低耦合”。采用“分而治之”的思想,把问题划分开来各个...
  • 表现层、控制层、逻辑层、DAO层

    千次阅读 2020-06-21 20:13:31
    表现层、控制层、逻辑层、DAO层是高内聚低耦合的结果。 1、表现层:主要功能是显示数据和接受传输用户的数据,...4、DAO层:操作数据(数据库或者文本文件等)的操作层,为业务逻辑层或控制层提供数据服务。 简单概括
  • BLL:(业务逻辑层): UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含:验证、计算、业务规则等等。 DAL:(数据访问层): 与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给...
  • 三层架构:表示层-业务逻辑层-数据访问层

    万次阅读 多人点赞 2016-12-21 16:50:47
    三层架构和MVC是两个东西。...三层架构中业务逻辑层和数据访问层对应MVC中的Model   由于层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是“无知”的,改变上层的设计对于其调
  • 架构:表示-业务逻辑-数据

    万次阅读 2018-08-12 23:32:53
    原文地址:三层架构:表示层-业务逻辑层-数据访问层 作者:灰烬 三层架构和MVC是两个东西。 非要相关的话: 三层架构中"表现层"的aspx页面对应MVC中的View(继承的类不一样) 三层架构中"表现...
  • 业务逻辑层接口设计

    千次阅读 2016-10-21 16:05:05
    业务逻辑层接口设计 业务逻辑层接口设计
  • 业务对象通常被认为是代表实体,比如 或者存储的类。 这样的类具有一定的属性,比如价格,颜色,宽度,... 业务逻辑层使用业务对象来访问数据库。 来自https://kb.kutu66.com/business-logic/post_786603 ...
  • 三层架构 业务逻辑层 workflow

    千次阅读 2019-04-17 14:59:23
    业务逻辑层 business logic layer 数据访问层 data access layer 系统的主要功能和业务逻辑都在业务逻辑层进行处理。 这里所说的三层结构,不是物理上的三层,而是逻辑上的三层。 业务逻辑层主要负责对数据层的...
  • 三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。
  • 三层架构 软件设计架构 界面层(表示层、变现层): 用户看的界面。 用户可以通过界面上的组件和服务器进行交互 业务逻辑层: 处理业务逻辑。 数据访问层: 操作数据存储文件。 三层架构和MVC ...
  • 视图层,业务逻辑层,持久层 (1)视图层:视图层很好解释 你现在看到的网页 一些界面 都属于表现层的东西可以用一些Html,jsp,Swing来实现 (2)业务逻辑层:业务层用来实现整体的业务逻辑 如 前台获得了数据,逻辑层去...
  • 表示层(让控制层调用业务逻辑层显示数据)业务逻辑(service比DAO更为细化处理判断,例如对某一个操作的细化)持久层(DAO,简单处理判断)数据库()
  • 传统项目开发中,代码分层架构大概是controller,Service,Dao,在SOA架构中会有facade,Service,Dao,两种方式都是将所有的业务逻辑集中在Service,包括业务参数的校验逻辑,业务的核心逻辑,对第三...
  • 细说业务逻辑

    千次阅读 2020-06-01 16:49:17
    2.1、业务逻辑到底是什么 2.2、业务逻辑的组成结构 2.2.1、领域实体(Domain Entity) 2.2.2、业务规则(Business Rules) 2.2.3、完整性约束(Validation) 2.2.4、业务流程及工作流(Business Processe...
  • 业务逻辑流程图

    万次阅读 多人点赞 2019-06-06 16:26:04
    用Axure注释逻辑 元件的逻辑有5种,具体如下: 功能逻辑:详细讲解该功能的逻辑。 交互逻辑:对页面之间的...在软件系统架构中,软件一般分为三个层次:表示层、业务逻辑层和数据访问层: http://www.360doc.com/con...
  • 业务层(service)需要根据系统的实际业务需求进行逻辑代码的编写,有些业务逻辑需要通过与数据库交互的,则业务逻辑层需要调用数据访问层的相关方法实现与数据库的交互,对于一些不需要与数据库进行交互的,则直接...
  • 数据访问层可能会操作不同的数据库,可是业务逻辑层我感觉没必要吧,不管从哪个数据库都是一种逻辑判断吧?我感觉没必要写两个实现类
  • 本文将以架构的方式去分析分层结构中的业务层设计,如何写出来内聚度,高耦合的业务逻辑层,并且如何根据我们的项目功能需要去设计业务层。我们将会通过几种可能的业务层设计模式去分析,分析每种设计模式的优点与...
  • java业务逻辑怎么写?

    千次阅读 2021-02-28 17:55:40
    现在Java项目一般都是用Spring全家桶开发,以web项目来讲结构主要分为Controller、Service和DAO,细分的话有的项目可能还会有一个Manager。一个请求到达后端之后会根据请求的路径找到对应的Controller,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 517,809
精华内容 207,123
关键字:

什么是业务逻辑层

友情链接: gost 19.201-78.zip