分层架构与业务逻辑实现方式.docx

分层架构与业务逻辑实现方式.docx

《分层架构与业务逻辑实现方式.docx》由会员分享，可在线阅读，更多相关《分层架构与业务逻辑实现方式.docx（9页珍藏版）》请在冰豆网上搜索。

分层架构与业务逻辑实现方式

分层架构与业务逻辑实现方法

一、分层架构

在当今软件系统中，常用的软件架构思想就是分层，分层思想是现代软件架构的主要思想。

无论是企业级应用系统（如：

CRM，ERP，OA，电子商务平台），专用软件（如：

OS、SVN、IDE等）,另有协议之类（TCP/IP，OSI等）绝大部分都采取分层架构思想进行设计的。

分层（Layer）不一定就是人们常说的二，三层，多层系统，因为这些说法都是分层架构的一些具体体现形式，分层是一种设计思想，也可以称之为一种软件架构模式（Pattern），这种思想的核心在于：

分别系统的职责（Responsibility），如果这个系统的职责你阐发清楚了，你的基于设计思路差不多就定下来了。

你可以去看看，许多的现在代软件，不是一定是web方面。

例如：

SVN这样的源代码治理软件、

图一：

SVN架构图

.NETFramework也是分层，Eclipse也是，TCP/IP越发是，另有像操纵系统（OS）、编译器（Compiler），许多流行框架（Framework）也是分层。

其实，MVC不也是分层，也就是把模型（Model）、视图（View）、控制器（Controller）三个差别职责离开。

那我们看看今天的企业级应用系统（许多说是web项目，其他我不认为是这样，因为web只是一种外在体现形式，我们可以用desktop步伐，flash等作为体现形式），企业级应用系统许多人一说就是三层架构，其实确实也是这样的。

即：

体现层，业务层，数据层。

虽然另有其他的分层，如：

体现层，办事层（办事外观层），业务逻辑层，数据映射层，数据层。

也有分成：

体现层，中间层，数据访问层等等。

（注意这些都是逻辑上分层结构一般用Layer，物理上的分层结构，一般讲的是摆设结构一般用tier）总体上都可以看成是三层：

体现层，业务逻辑层（也可以说是领域层或领域逻辑层），数据层。

像Spring,Structs、ORM等一些框架，他们都是在差别的层上的相关实现技能。

二、业务逻辑几种实现方法

现在我们再看看，企业级系统中最核心是哪一层？

肯定是业务层，因为企业级系统主要是与业务打交道（其实险些所有软件都是实现业务，企业级系统业务逻辑主要偏向于商业逻辑，其他系统，像游戏，自动化控制、支撑系统等把业务看成是算法），并且业务是每个系统都不尽相同的。

“业务逻辑是最没有逻辑的东西”[FowlerPoEAA,2003]。

并且企业级系统的变革与改变大多都在业务层上。

那么，做好企业级系统，首先主要阐发好业务系统。

你可以看看，现今所有的框架在整体结构（spring,structs,等要求系统按MVC结构来开发），体现层（jquery,extjs等），与数据层（ORM之类）做得最多，有没有业务的框架？

（有，但是很少，并且只能是业务比力有规律的地方，像一些财务系统，有些权限系统，虽然另有事情流系统）因为业务逻辑每个系统都很可能不一样，没步伐通用。

那么有什么步伐以比力好的方法实现业务逻辑呢。

现在终于说到主要问题上来了：

也就是业务逻辑（BusinessLogic）的实现方法，也叫做领域逻辑（DomainLogic）的实现方法。

一般来说，有以下几种：

1．事务脚本（Transactionscripts）

2．领域模型（DomainModel）

3．表模块（TableModule）

4．运动记录（ActiveRecord）

我们用得最多就是事务脚本方法（像微软的Petshop4.0,许多国内的三层结构代码生成东西生成的系统，并且这种方法许多公司，许多企业级的项目都在用，另有一些框架引导你用这种方法实现）。

这种方法最大的特点就是：

简单实用。

为什么叫事务脚本（Transactionscripts）呢？

也就是实现一个成果，就直接写一个历程（要领），系统的业务就是疏散在一个个这样的历程里,像早期用ASP做的大部分系统，一些使用存储历程系统等，尤其是使用存储历程系统，所有业务逻辑都写在存储历程里，很明显的事务脚本实现方法。

想一想，我们在业务层实现一个业务时，一般就是这么做的，要实现一个什么成果，在脑子里想一想，然后找到那个对应的类，然后再界说一个要领，加上一堆参数。

就开始写这个要领的实现代码，要是逻辑庞大点，这要领里一堆ifesle，是不是？

如果逻辑不庞大，这种实现到没什么问题,也很方便的。

并且，有时候，发明一个类里许多多少要领，并且大部分是public的。

有时候仔细看看，这个类已经不再是按面向东西方法来实现，虽然你用的是OO语言（java,C#,Ruby等），也用了类，接口，继承、多态等技能手段，但是你是否发明系统中东西之间的协作是多么难，甚至你都觉得系统都不存或很少有几个东西协作完成一件事情的，有时你会迷惑许多业务层的类是否应该直接界说成静态类就可以了，底子不需要实例化成一个东西。

你还发明，有些要领（成果职责）底子不属于这个类或东西的。

这样一来一去，类的职责乱了，要领多了，代码也没重构，越来越乱，最背面都大了。

所以这就是事务脚本的特点，业务不庞大的系统用这样方法很方便，对技能人员要求也不是很高，因为它的实现思维照旧按历程方法，大部分步伐员都习惯性这样，但是一旦业务变革庞大，系统日益不绝的变革，这种方法就变得不堪重负了。

领域模型（DomainModel），你也可称它为业务模型，这种方法是现今在国内外许多大家级人物提倡的实现方法。

这种方法最大的利益，它采取是面向东西方法来阐发与设计业务逻辑，许多经验不敷的人就会反问，难道我用事务脚本方法就没有用面向东西的方法还阐发与设计，我系统里面可全是类、继承，接口等，那我请问你，你每个类职责单一（SRP）么？

大概说你把每个类的职责分派好了没有，就像你会用C#、java、Ruby了，那为何还会有《设计模式》呢？

我想许多人都市沉默沉静一下，其实要把职责分清楚是一件不容易的事，但也不是不可能，这需要富厚面向东西阐发与设计及步伐设计的经验（许多人觉得不需太多编码经验，我小我私家是很阻挡的，因为只有对步伐设计语言也很熟悉，才直正设计出优秀系统，特别是每种语言在差别平台、框架照旧有细微的差别的），还要准确理解与掌握系统的业务需求，再经过不绝迭代，精化才最终得出一个比稳定的业务模型。

引申《重构》的一句话：

“任何傻瓜都能写出盘算机可以理解的代码，唯有写出人能容易理解的代码才是优秀的步伐员”[Fowler2002]。

那是不是：

任何了解OO语言的人都市使用类、接口、继承等特性写代码，唯有能写出职责明白，结构清晰的代码才是优秀的面向东西步伐员呢？

“领域模型实现方法，不再是由一个历程来控制用户某一行动的逻辑，而是由每一个东西都包袱一部分相关逻辑”[FowlerPoEAA,2003]。

也就是说实现一个业务，是相关领域东西的一系列协作与交互的结果，不再像事务脚本那样直接在一个历程中。

这比如一小我私家要完成一个行动都是人体各个器官相互相助协调来完成的，什么时候你见过一个行动，如用饭，我只要口张开就可以了。

因此，领域模型实现方法，它一般会先进行业务建模，有时候把业务模型也称之为看法模型，我们在干系数据库理论里有E-R模型，所以有些人也称之为实体模型。

其实，业务，看法模型与实体模型照旧有区别的业务模型其实是现实问题域进行阐发或抽象，这与实体差不多。

但是业务模型最终要是用OO方法去试，实体模型要映射成干系模型。

因此，业务模型在后期迭代与精化时，不得不采取一些OO手段，如东西职责（Responsibility），脚色（Role），协作（Collaboration）等。

并且实体模型则要考虑干系映射，查询优化，数据冗余的问题。

如果你用面向东西方法来实现系统，业务层实现方法采取领域模型方法来实现是最好的，因为他直接与OO语言映射，思维方法与实现方法统一，所以他可以解决很庞大的业务系统，并且还可以得到很好扩展性，维护性与复用性。

我可以具体说明：

例如interactiong项目，那个消息发送战略，

图二消息发送模型

之前的实现方法是写了三个要领（SendMail,SendMSM,SendSMS）在一个类里，这一看，显然的事务脚本实现方法，底子没有去抽象与阐发当前的领域逻辑，没有用OO方法去阐发与设计当前问题，如果那天还要实现一个发送彩信或者去掉发送手机短信的成果，那还修改原来的类，这显示违背对扩展开放对修改封闭的原则（OCP）。

这地方明显就是一个战略模式。

另有，像发送者，与吸收者，消息这些东西都是可以具有行为，因为领域模型是归并了数据与行为的东西模型。

像Petshop的model层，就是一个贫血模型，一个实体东西没有任何行为（要领，操纵）。

现实中确实可以有一个东西没有行为，但是那肯定是少数。

一般来说，一个东西肯定有数据与行为。

只有行为没有数据类，就叫无状态类（statelessclass）

只有数据没有行为，一般用于DTO（数据传输东西[DataTransferObject]，这在远程调用与漫衍式调用中常见的一种设计模式）

因此，像这些发送者，吸收者，消息这些类是应该具有行为的，像消息解析器，发送器，这些应该是办事类。

所以基于领域模型的系统一般系统分成：

体现层（Presentation，应用步伐层（Application），领域层（Domain），底子结构层（Infrastructure）。

应用步伐层其实比力弱，有时候也可以叫做办事外观（ServiceFacade），有时候可以不需要这一层；领域层，就是业务逻辑层，它包罗领域东西与领域业务的一些实现，还资源库（Repository）东西，资源库相当于数据访问东西（DAO），主要用于数据访问，增、删、改、查（CRUD）等；底子结构层，可以包罗在许多，数据长期化（DataPersistence）、ORM、宁静机制（Security）、数据验证（DataValidation）、异常处理惩罚（ExceptionHandle）、日志跟踪（Tracing），缓存机制（Caching）、IoC、AOP等,许多模切（CrossCutting）组件都可以在这层提供。

这种分别，是一种经典的领域驱动设计分别，不一定严格按此方法。

表模块（TableModule），我小我私家认为表模块应该不算是一种业务逻辑实现方法，但是凭据MartinFowler《PoEAA》一书，把其归类到领域逻辑模式中，它是处理惩罚某一数据库（其实只能是干系型数据库）中表与视图所有行的业务逻辑的一个实例。

因为表模块其实就一个数据聚集（如：

ado的RecordSet,的DataSet中的DataTable或类型化DataSet等之类），它可以看成是一个数据容器，因为他用一个类（如Product）体现数据库中对应表所有数据及行为，我们知道面向东西模型与干系模型存在差别，通常一个类与一个实体在看法上相对应，也就是一个类对应一个表，一个类的实例，即东西对应表中某一行记录。

类与表都是抽象的，聚集的看法，像干系数据库中表就一个二维（行、列）的聚集，而表模块用一个类直接体现表中所有数据及行为，所以这个类可以不需要实例化，它就相当于一个表（如.net的DataTable），这样所有业务操纵都直接用表模块方法进行，从这一看法上来说，它也可以看成是业务逻辑的一种实现方法，其实大家肯定可以得出，这种方法在本质上照旧采取事务脚本方法来实现业务逻辑，只是事务脚本方法，经常要求处理惩罚一个业务逻辑（如：

查找指定ID的Product）就需要用SQL语句从数据库中获取数据，而这种方法先把数据库的所有行加载到表模块（如：

DataTable）中，之后处理惩罚所有业务都直接与表模块有关（如：

查找指定ID的行，CRUD之类的操纵）,这正是表模块与事务脚本的细微区别之后。

运动记录（ActiveRecord），它本质上是一种领域模型。

它体现一个东西，其包装数据库表或视图中某一行且封装数据库访问，并在这些数据上加上了部分领域逻辑。

图三一个运动记录的类

从上