用微软.NET架构企业解决方案 学习笔记（四）业务层

 

业务层

 

 

引言

　　Martin Fowler说过：“任何人都可以写出计算机才能理解的代码，只有写出人能理解的代码的程序员才是好程序员。”

　　每一个复杂的软件都应该按层来组织。每一层代表系统的一个逻辑部件。尤其是，业务层的模块包括了所有使得系统运行的时候和其它层交互所需要的功能算法和计算，其他层包括数据访问层DAL和表现层。

　　业务层是任何分层系统的神经中心，包含了大部分的核心逻辑。因为这个原因，它也经常被叫做：业务逻辑层BLL。

正文

　　1、业务逻辑层是什么

　　抽象的讲，业务逻辑层是系统的一部分，用来处理和业务相关的任务。本质上，业务逻辑层包括一系列执行数据的操作。数据被模型化为问题域的实体，例如：发票、用户、订单、清单。另一方面，包括一些操作，例如：创建一个发票，添加一个用户，处理一个订单。

　　2、剖析业务层

　　如果你从纵向来看业务逻辑层，你会发现一些业务模型的实体，表达用户策略和需求的业务规则，实现自动化功能的服务，定义文档和数据从一层流转到一层的工作流。

　　安全是一个在所有层都需要考虑的严重问题，但是在业务逻辑层，代码扮演一个用户界面层的守门人。在业务逻辑层的安全是以角色为基础的，或者是限制对业务对象的访问，只对授权用户开放。

　　2.1、领域对象模型

　　领域对象模型更倾向于对整个系统提供一个结构化的视图，包括实体的功能描述，实体间的关系，实体的职责。模型产生于用户需求，使用UML的用例图和类图进行文档化。在模型中，你表示出用来存储数据和暴露操作的真实世界元素。每一个实体代表模型中的一个角色，提供一些行为。每个实体都有自己的职责，依据领域的关系进行交互。

　　很多应用被打上复杂的标记，实际上，如果你看到最终的技术实现，你会发现是相对简单的。但是，整体来看这个应用是复杂的，那是因为领域内在的复杂性。通常来说，困难在于构建一个适当的软件模型，而不是最终的实现。一个设计良好的模型，无论你运行到哪里，可以解决任何难度的复杂性。

　　

　　对象模型和领域模型

　　为了清晰起见，让我们确定一下“对象模型”和“领域模型”这两个词。尽管我们经常会交替使用，实际上他们代表不同的事物，就算代表同一个事物的时候，他们的抽象级别也是不同的。我们所谓的“对象模型”就是简单的对象图。对于如何设计和实现模型没有限制。如果你有了一些相互关联的类，就有了一个对象模型。就像你看到的，描述相当通用，适用于大部分的解决方案。

　　我们所谓的“领域模型”就是另外一回事了。领域模型是用来满足一系列需求的对象模型。典型的，领域模型中的类没有持久层的概念，是一种与其他帮助类库中的类没有关系的理想状态。另外，领域模型设计用来解决特定的领域问题，试图从实体和它们之间的关系来抽象业务流程和数据流。

　　记住领域模型也是一种特殊的设计模式，在后面我们会讨论。

　　2.2 领域实体

　　从外部来看，业务逻辑层就是对业务对象的一系列操作。大多数情况，一个业务对象就是一个领域实体的实现，也就是一个封装了数据和行为的类。也可能是一些实现特殊计算的辅助类。业务逻辑层决定业务对象之间如何交互。它也为参与交互的模块、业务对象强加了一些规则和流程。

　　业务逻辑层处在一个分层系统的中间，和表现层、数据访问层交换信息。业务逻辑层的输入和输出不是非要业务对象不可。在大多数情况，架构师更倾向于在跨层之间使用DTO(Data Transfer Objects)进行数据传输。

 　　业务对象和数据传输对象有什么不同呢？

　　业务对象包含数据和行为，在业务逻辑中可以看做是充血的活动对象。数据传输对象只是一个值对象，是包含数据没有附加的行为。处于序列化的目的，在业务对象中存储的数据需要被序列化到数据传输对象中。数据传输对象除了setter和getter以外没有逻辑行为。在模型中，每一个领域实体类可能会对应多个数据传输对象。为什么是多个数据传输对象呢？

　　一个数据传输对象不是一个无行为的领域对象的简单副本。相反，一个数据传输对象代表一个在特定上下文环境使用的领域对象的子集。例如：在一个方法中，你需要一个只有Name和ID的CustomerDTO；其他地方你可能需要一个有Name、ID、Country、Contract的CustomerDTO。通常来说，一个领域对象是一个包含很多对象的图，例如：Customer包含orders，orderdetails，等等。

 

 　　重点

　　关于DTO和OB的协同使用，可以引出一大串的、无意义的争论。理论建议在任何情况下都是用DTO来减少层之间的耦合。实践中，经常会提醒我们已经够复杂的了，尽量避免不必要的附加东西。作为一条实践的准则，我们建议在处理少于100个业务对象的模型的时候，你不需要这么做。在这些情况下，DTO和OB很可能很相似。

　　2.3 业务规则

　　在现实世界中的组织都是基于一系列的业务规则组成的。你可以争论这些规则的级别，但是不可以否认这些规则的存在。每一个组织都有追求的战略，规则是实现战略的主要规范。战略指明了要达到的高度，规则明确了如何达到这个高度。

　　规范业务规则有各种方式。如果你生活和工作在一个完美的世界，每一个组织维护他自己的规则数据库，这样在一个项目中的各个团队中就很容易共享这些规则。大多数情况不是这样的，搜集业务规格的过程开始于开发项目。结果就是，业务规则在项目快要结束的时候才整理出来，而且是在架构师之间共享。

 　　依赖于进行操作的上下文环境，业务规则不是固定的，是变化的。这就意味着在业务逻辑层中，应该以一种灵活的方式实现规则，最好是通过规则引擎实现。在最高级别的抽象中，规则引擎是软件的一部分，以某种规范引入规则，并且应用于业务对象。

　　在实际中，业务规则通常就是一系列的if。。。else。。。语句，映射为业务对象的操作，也就是所谓的业务逻辑。

　　在实际的系统中，一个的业务对象可能会映射出上千条规则。你的规则引擎应该足够灵活，以适应可能的变化以及修复一些误解。

　　2.4 验证

      业务对象的属性来自于实体的属性。业务对象的方法来自于自己的一系列职责。

     

   

　　未完待续。。。。。。。。。。。。。。。。。。。。。。。。。。。