走向走向ASP.NET架构设计架构设计—第四章第四章—业务层分层架构(前篇)业务层分层架构(前篇)
前言:在任何一个项目中业务层毫无疑问是最重要的层,所以在设计的过程中,如何组织业务层是至关重要的。本章的讨
论将会涉及Flower的架构模式一书中的四种组织业务层的模式:Transaction Sript,Active Record,Anemic Model 和Domain
Model。每一中组织业务逻辑的模式有着各自都优缺点,如何选择他们重要的还是取决于我们所要开发的项目的类型。
在讨论完四种模式之后,我将会和大家一起来看看DDD的一些知识。
每种模式的讲解,我都会用实例的形式给出完整的代码,也希望大家多琢磨!
不是所有的应用程序都是一样的,也不是所有的系统都需要用复杂的架构来组织业务逻辑。作为开发人员,我们必须清楚每
一种业务逻辑组织的模式,这样我们才能在需要的时候做出合适的选择。
Transaction Script
这种组织业务逻辑的模式是最简单,也是最容易理解的。Transaction Script模式就是用面向过程的方式来组织业务逻辑的。
通常情况下,系统的一个流程就被实现为一个方法,然后把所有的这些方法组织在一起,放在一个静态的manager类或者
service 类中。实现流程的那个方法包含了业务逻辑的Check和Validation,数据的持久化以及其他的一些相关操作。也就是
说,一个方法把所有的事情都做完了。当然,有时候这个大的方法还可能被拆成小的方法,便于重用。如下图所示:
Transaction Script一个好处就是理解起来很简单,尤其是当Team中的一个新成员来说,更是如此,因为他几乎不用花什么
时间,就能立刻明白这种组织业务逻辑的方式。每当来了一个新的需求的时候,要做的事情就是去加上一个或者一些新的方法
来是实现这个需求,而其还不会影响其他已经存在的功能。
对于一个很小的或者基本山没什么业务逻辑的系统来说,用Transaction Script模式组织业务逻辑还是很不错的,而且对一个
刚刚踏入IT的开发人员门槛也比较低。:当系统开始变大,业务逻辑开始变得复杂的时候Transaction Script的问题的出来了。
最后的结果可能就是系统中存在大量的方法,而且这些方法中到处都是重复的代码。有的时候,我们可以提炼出一些业务逻辑
的验证代码组织为方法,但是我们去很难提炼出一些在流程上相识的代码,即使两个流程只有一点点的不同。如果系统的需求
稍微一边,导致流程变了一点点,那么很多的方法就要改动,而且我们还得在系统中去找出那些相似的流程代码,然后修改,
万一哪个方法没有找出,后果可想而知。
下面我们就用一个人事请假管理系统为例子来看看Transaction Script是如何实现的。因为Transaction Script很简单,所以下
面的代码也只是用于演示,大家理解就行了。
代码
public class HolidayService
{
public static bool BookHolidayFor(int employeeId, DateTime From, DateTime To)