系统架构师-基础到企业应用架构-业务逻辑层
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了系统架构师-基础到企业应用架构-业务逻辑层相关的知识，希望对你有一定的参考价值。
一、上章回顾
上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计，我们也讲述了通过分离功能点的方式来实现，而在软件开发过程中的具
体实现方式简单的分为面向过程与面向对象的开发方式，而目前更多的是面向对象的开发设计方式。并且我们也讲述了该如何通过设计手段去分析功能点及设计分离
点，应该如何在设计的过程中分析的角度及如何去满足设计规范与原则。首先我们通过下图来回顾下上章要点：
二、摘要
本文将已架构的方式去分析分层结构中的业务层的设计，如何写出来内聚度，高耦合的业务逻辑层，并且如何根据我们的项目中的个功能需要去设计业务层。我
们本章将会通过几种可能的业务层的设计模式去分析，并且分析每种设计模式的优点与缺点及每种设计模式的应用场景,并且结合一定的使用实例来讲解，当然这些具体
的内容都是自己在项目中的经验与总结。错误之处，在所难免，本人抱着求真务实的态度，争取写好每一篇文章，错误之处还请大家匹配之处，如果您有好的意见或建
议，可以及时跟我沟通，如果对系统架构中的设计规范与模式不了解，可以点击这里查看上篇文章：系统架构师-基础到企业应用架构-系统设计规范与原则[下篇]
本章讲解的内容我们先看下图中的几个简单模式：
三、本章大纲
1、上章回顾。
2、摘要。
3、本章大纲。
4、业务层设计分析。
5、几种不同的业务设计模式。
6、本章总结。
7、系列进度。
8、下篇预告。
四、业务层设计分析
本节中将会对业务层的设计进行详细的分析。
首先、我们知道业务层是一个系统中最核心的部分，业务层是实现系统业务功能的核心逻辑层。业务层我们通常说的BLL(Business Logic Layer)层，现在我们
一般的稍微复杂一些的业务逻辑都是通过分层结构来构建一个应用系统，我想大家在组织业务逻辑功能时大部分的情况下是使用BLL层单独负责相应的业务逻辑来实现
的。有些应用可能业务逻辑层并不复杂，这是我们可以把问题简单化，不用引入一些框架性的东西来提升系统的复杂度，但是有些业务规模较大，并且业务逻辑性较强
时，可能使用好的业务设计模式带来的优越性就显而易见了。 我们大家都知道业务逻辑层主要是用来处理领域模型对象之间的逻辑关系的部分。我们都知道业务层的数
据最终是要保存到数据库中，我们在进行业务层设计时一般是在架构中的分层架构模式中出现的。我们知道分层结构中一般是将领域模型与底层数据访问、表现层等进
行分开组织，这样可以让系统结构上清晰，并且容易降低他们之间的耦合性。
其次、其实我们的很多操作都是可以在业务层来完成，比如说用户的角色权限，数据验证等一些基本的业务规则。当然这里说明业务层主要负责系统中的业务规
则的实现。这里我们需要知道2个概念，就是对象模型与领域模型：下面我们说下这2者的区别。
描述对象模型与领域模型的区别。
最后、业务逻辑层作为分层系统中的中间位置，业务模型是表现层与数据层之间的纽带。当然一般我们在系统设计时，可能我们一般不会把领域模型中的领域实
体作为分层之间的传输信息，因为一般来说领域模型中的实体不但包含实体的数据信息，并且包含实体的行为。可能我们在各层中只会用到实体的数据信息，那么无疑
这时采用领域实体的形式进行传输，那么会增加系统的传输负载。当然这里就会出现我们平时所谓的3层模式中的Model层。当然Model层设计的主要作用就是实体数据
的承载，其中并不包含任何行为。具体的行为通过数据访问层来实现CRUD（DDL中的四个基本操作）的操作。
目前我们设计的分层结构中的对象模型中并不包含实体的行为。其实这里可以看作是比
较好的设计方式，因为采用对象模型的方式进行数据传输时可以降低系统的耦合。当然我们也可以把领域实体看作是多个对象实体的组合并且包含这些对象实体之间的
关系。所以我们在做系统架构时可能如何权衡就比较重要，具体是使用领域实体进行数据传输还是对象实体主要还是看业务的需要。
五、几种不同的业务设计模式
首先我们在业务逻辑层设计时，必须首先确定是采用面向过程还是面向对象的模式来设计。 下面我们就将针对开篇介绍的几种模式进行分别介绍，错误之处请大
家批评指出。我们首先来讲解过程式的2类逻辑层的架构模式。
过程式模式
1、事务脚本模式
事务脚本模式是面向过程的模式，那么我们就不会采用面向对象的设计思想。这种模式是将业务代码映射到用户的操作中。简单的理解就是将用户的每个操作
都对应一个方法，那么这个方法就是我们这里讲的事务脚本。 当然这里的“事务”就是指我们平时说的业务流程，“脚本”则是我们说的流程中的相应操作方法。这里
需要注意的是 ,不要认为数据库操作的相应方法也属于脚本中的内容，我们通常还是将数据访问层单独的书写，只不过脚本中调用而已。
通常，事务脚本模式中都是一系列的逻辑判定或者循环或其他方式，通过一系列的函数调用来实现业务流程的。通常来说一般业务比较单一或者不是很复杂的
系统功能，通过该模式实现起来会比较简单。而且如果业务流程中的变化较为频繁的话不建议使用该模式来做。我们认为，我们对于这类简单的功能，我们没有必要花
费较大的代价去设计领域模型和其他方面的考虑。
事务脚本模式的一大优势就是很简单，没有开始时的额外代价，它可以很好的进行快速的应用程序开发，一般情况下来说，如果一个项目的时间紧迫，逻辑简
单，并且使用强大的开发工具时，我们可以使用这样的模式来进行，无论是成本还是开发效率上都非常客观。
我们根据上面的介绍可能认为，事务脚本模式的可重用性不高，并且耦合性太高，适应性并不好，当时我们仍然可以通过我们好的设计来实现代码的重用，
我们可以在进行“脚本”编写时将重用的部分抽象出来，写一个单独的函数，以达到复用的目的。
事务脚本模式的一个重大缺点就是通过这样的设计很容易造成代码重复，通常来说我们很容易完成一系列的业务功能，但是随着应用程序功能的增加，那么应用
程序代码会变成非常复杂的程序结构，当然我们可以通过重构去环节该模式的这一劣势，当规模达到一定程度时，我们同样没办法去完成重构工作。
通过上面的讲述，我们对事务脚本模式有了初步的认识，那么下来我们看看我们在进行业务逻辑层设计时的详细使用该模式的步骤及相关准则。
本图描述了事务脚本模式的设计过程，那么基本上每个系统流程都可以通过这样的流程来完成设计。下面我们就针对一个简单的实例来讲解下
如何通过这样的设计流程来实现系统的功能。
我们这里以简单的购物流程来讲述。如何下一个订单
首先、我们先来分析下用例：
我们知道注册的会员可以通过将产品添加到购物车中，然后通过去付款模块来进入支付系统，完成订单。
其次、分析出事务。
一般来说购物的流程是这样的流程。当然这里也不是标准的形式。
那么我们如何上述的几个步骤的内容，去完成这个事务的流程。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
public class BuyInfo { /// <summary> /// 购物车中的产品列表 /// </summary> private List<Product> proList = new List<Product>(); public int CreateBuyCar(Product product) { //事务开始 this.BeginTranstion(); //判定当前添加到购物车中的产品信息是否是自己发布的产品 if (!this.IsCanBuy(product.PutOutID)) return; //判定当前产品的库存信息是否大于当前购买的数量; if(!this.IsLagerThenBuy(product.PutOutID)) return; //添加产品到购物车 proList.Add(product); //处理生成订单信息 int orderID= this.CreateOrder(); //事务结束 this.EndTranstion(); return orderID; } /// <summary> /// 生成订单 /// </summary> /// <returns></returns> private int CreateOrder() { Order order = new Order(this); return order.CreateOrder(); } /// <summary> /// 判定当前产品的库存信息是否大于当前购买的数量 /// </summary> /// <param name="p"></param> /// <returns></returns> private bool IsLagerThenBuy(int p) { return false; } /// <summary> /// 判定是否是自己发布的产品信息 /// </summary> /// <param name="p"></param> private bool IsCanBuy(int p) { return false; } private void EndTranstion() { //TODO.. } private void BeginTranstion() { //TODO.. } } |
这里定义的是添加到购物车的流程，下面将给出如何将购物车中的产品信息添加到订单中的具体流程。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
public class Order { private BuyInfo info; public Order(BuyInfo buyInfo) { info = buyInfo; } public int CreateOrder() { //将BuyInfo购物车中的产品列表与订单信息进行关联。 this.InitOrderInfo(); //将订单中的会员信息关联 this.InitOrderUserInfo(); //将订单中的收货信息关联。 this.InitOrderReciveInfo(); //将订单中的支付信息关联。 this.InitOrderPayInfo(); //生成订单。 } /// <summary> /// 将购物车中的产品添加到数据库中 /// </summary> private void InitOrderInfo() { throw new NotImplementedException(); } /// <summary> /// 初始化订单的支付信息 /// </summary> private void InitOrderPayInfo() { throw new NotImplementedException(); } /// <summary> /// 初始化订单中的收货信息 /// </summary> private void InitOrderReciveInfo() { throw new NotImplementedException(); } /// <summary> /// 初始化订单的买家信息 /// </summary> private void InitOrderUserInfo() { throw new NotImplementedException(); } } |
通过上面的形式基本上就完成了简单事务脚本模式的构建，当然我们也可以将所有的一系列的脚本封装到一个类里面，通过静态方法的方式来访问也是可以
的。只是组织方法的形式不同。当然我这里提高了，通过将脚本封装到一个类里面，通过静态方法的形式或者实例方法的形式都是可以的，那么我们来讲讲什么时候
封装成静态方法，什么时候封装成实例方法。
我们如何将数据传入给实体脚本呢，通常我们是通过前面我们说的对象实体来完成的，因为数据对象实体只是包含实体的数据信息，并不包含具体的行为。
那么我们来简单说说对象实体中的信息及格式，我想大家用过分层结构中的Model层的都会比较的清楚，下面我们看看，不详细介绍了：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
public class Product { private int putoutID; public int PutOutID { get { return this.putoutID; } set { this.putoutID = value; } } private int productID; public int ProductID { get { return this.productID; } set { this.productID = value; } } private int productName; public int ProductName { get { return this.productName; } set { this.productName = value; } } private int productUnit; public int ProductUnit { get { return this.productUnit; } set { this.productUnit = value; } } private int productClass; public int ProductClass { get { return this.productClass; } set { this.productClass = value; } } } |
我们看到了主要是通过get；set访问器来实现的。
总结：业务逻辑层是将表现层触发一系列事务分别实现，那么对业务逻辑层的建模其实就是对事务的具体实现，将事务映射到业务逻辑层中的不同方法上，一
般来说事务代码维护起来比较难以维护，重用性低，难以理解。
2、表模块模式
表模块模式是对事务脚本模式的实践总结并优化而提出的新模式。相比而言，表模块模式结构性更强，总体来说，表模块就是就是将数据库中的某个表上的所
有可能的操作都写在一个类文件中，这个类文件中定义了该数据库表对应的所有的业务方法。表模块类是一个容器，它内部包含了类的数据信息和相应的行为。表模块
是映射数据库表的关系，因此表模块对应的是数据集合，那么无法将数据库表中的某个行记录进行区分，只能通过集合中的键或者索引来访问行记录的信息。
表模块模式由于是在事务脚本模式发展的更有结构化的模式，那么可以说表模块模式虽然是面向过程的模式，但是它朝面向对象的模式已经迈了很大的一步，
我们知道,在将对象模型中的数据保存到关系数据库中时，需要使用相关的ORM工具去完成相应的转换。我们知道面向对象模型能够很灵活、更好的对领域模型建模。当
然，表模块模式仍然关注的是方法，而不是对象。
通常我们在更好的结构设计指导的同时，那么我们需要考虑更多的规则，那么意味着我们需要书写更多的代码。表模块模式的具体实例可以参考Visio Studio
中的提供的DataSet和dataTable。
表模块在处理简单的实体时具有很好的优势，但是当实体较复杂时，或者实体之间的关系紧密时无法很好的处理。下面我们来看看一个简单的例子来说明表模
式的使用。我们这里还是以刚才事务模型中的购买流程来讲解。
数据库表与表模块类的映射关系是通过.NET提供的内存数据对象DataSet、
DataTable来实现。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
public class Order { private System.Data.DataTable _orderItems; private DataSet _ds; public Order(DataSet ds) { _ds = ds; } /// <summary> /// 返回订单对应的所有产品信息 /// </summary> |
以上是关于系统架构师-基础到企业应用架构-业务逻辑层的主要内容，如果未能解决你的问题，请参考以下文章