架构设计-业务逻辑层简述

    业务逻辑层是专门处理软件业务需求的一层,处于数据库之上,服务层之下,完成一些列对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--破狼。http://www.cnblogs.com/whitewolf/archive/2012/05/29/2524881.html

时间: 2016-05-23

架构设计-业务逻辑层简述的相关文章

三层架构中业务逻辑层的实现方式有哪些

问题描述 如题,比如说webservice,最好是应用程序和网页都能调用的接口 解决方案 解决方案二:BLL层一般都是继承接口实现,使用接口可以扩展业务逻辑.解决方案三:引用1楼duanzi_peng的回复: BLL层一般都是继承接口实现,使用接口可以扩展业务逻辑. 我就是想问接口的实现技术有哪些解决方案四:目前比较流行的是wcf解决方案五:所谓"业务逻辑",就是你的业务所需要处理的逻辑呀!虽然数据的增删改查也是业务,但一般直接放在数据访问层实现.举个例子,你用三层来实现登录的话,判断

多层架构在业务逻辑层实现IOC

在业务逻辑层实现IOC,可以有效的减少代码量,把通用的操作写在通用的类中,然后在UI层对谁操作就建立谁的实例. 具体做法看代码: Service层核心代码: 接口规范: namespace Service { /// <summary> /// 标准逻辑处理接口 /// </summary> /// <typeparam name="TEntity"></typeparam> public interface IServices<T

《解剖PetShop》系列之五:PetShop之业务逻辑层设计

业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分.它的关注点主要集中在业务规则的制定.业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,很多时候,我们也将业务逻辑层称为领域层.例如Martin Fowler在<Patterns of Enterprise Application Architecture>一书中,将整个架构分为三个主要的层:表示层.领域层和数据源层.作为领域驱动设计的先驱Eric Evans

《解剖PetShop》之五:PetShop之业务逻辑层设计_自学过程

五 PetShop之业务逻辑层设计 业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分.它的关注点主要集中在业务规则的制定.业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,很多时候,我们也将业务逻辑层称为领域层.例如Martin Fowler在<Patterns of Enterprise Application Architecture>一书中,将整个架构分为三个主要的层:表示层.领域层和数据源层.作为领

基于.NET平台的分层架构实战(十)—业务逻辑层的实现

在这一篇文章中,将实现一个NGuestBook的业务逻辑层. 在实际应用 中,业务逻辑层是至关重要的,他承载着整个系统最核心的部分,也是客户最关 注的部分.这一部分的实现,通常需要技术专家和领域专家通力合作.当然,在 本文章系列的Demo中,由于业务逻辑的简单性,这里看的可能还不是很明显. 在本篇文章的业务逻辑层实现中,业务逻辑层主要承担了以下职责: 1.对不同数据访问层的封装.使得表示层可以不关心具体的数据访问层. 2.业务逻辑数据的填充与转换.如管理员口令的加密. 3.核心业 务的实现.这里

ASP.NET MVC5网站开发之业务逻辑层的架构和基本功能 (四)_实用技巧

业务逻辑层在Ninesky.Core中实现,主要功能封装一些方法通过调用数据存储层,向界面层提供服务. 一.业务逻辑层的架构 Ninesky.Core包含三个命名空间Ninesky.Core.Ninesky.Core.Types.Ninesky.Core.General. Ninesky.Core包含模型和功能实现,Ninesky.Core.Types是项目用到的一些类型的定义,Ninesky.Core.General是项目用到的一些方法的定义. 1.Ninesky.Core命名空间的结构 Ni

ASP.NET2.0数据操作之创建业务逻辑层

asp.net|创建|数据 导言 本教程的第一节所描述的数据访问层(Data Access Layer,以下简称为DAL)已经清晰地将表示逻辑与数据访问逻辑区分开了.不过,即使DAL将数据访问的细节从表示层中分离出来了,可它却不能处理任何的业务规则.比如说,我们可能不希望产品表中那些被标记为"停用"的产品的"分类编号"或"供应商编号"被更新:我们还可能需要应用一些资历规则,比如说我们都不希望被比自己的资历还要浅的人管理.另外一个比较常见的情况就是

ASP.NET MVC+EF框架+EasyUI实现权限管理系列(4)-业务逻辑层的封装

原文:ASP.NET MVC+EF框架+EasyUI实现权限管理系列(4)-业务逻辑层的封装 ASP.NET MVC+EF框架+EasyUI实现权限管系列 (开篇)   (1):框架搭建    (2):数据库访问层的设计Demo    (3):面向接口编程 前言:前面几篇博客我们基本已经介绍完了搭建整个项目和数据库访问层以及一些业务逻辑层的实现,当然了,我们的数据库访问层这样还是可以在进行封装的,但是我到这里就行了吧,项目也不大,不需要那么麻烦的,那么我们今天开始介绍我们需要介绍的内容,那就是我

Scott Mitchell的ASP.NET 2.0数据教程之二:创建一个业务逻辑层

返回"ASP.NET 2.0数据教程目录" 导言 本教程的第一节所描述的数据访问层(Data Access Layer,以下 简称为DAL)已经清晰地将表示逻辑与数据访问逻辑区分开了.不过,即使DAL将 数据访问的细节从表示层中分离出来了,可它却不能处理任何的业务规则.比如 说,我们可能不希望产品表中那些被标记为"停用"的产品的" 分类编号"或"供应商编号"被更新:我们还可能需要应用一些 资历规则,比如说我们都不希望被比自己的