第二章:管理领域逻辑
三个主要的模式:Transaction Script,Domain Model,Table Model
最简单的方法是使用Transaction Script,Transaction Script本质上就是从表现层接受输入,进行验证和计算,保存进数据库,调用其他外部操作并且返回更多的信息,帮助计算并组织数据给表现层的过程。基本上就是将用户可能做的事情组织成一个个的函数,所以可以将其想象成动作的脚本,或者一个个事务。
Transaction Script的优势:
- 是几乎每个开发者都了解的简单的过程模式
- 配合使用简单的数据库层模式,如Row Data Gateway,Table Data Gateway时工作的很好
- 非常明显的边界:以打开事务开始,关闭事务结束。
但是,在领域逻辑变得越来越复杂时,Transaction Script也会有很多劣势,会出现很多难以消除的重复代码,子方法越来越多后,缺乏清晰的结构。
这个时候,就该以面向对象方式处理逻辑的Domain Model模式登场了。我们主要围绕着领域中的名词来建立Domain Model模式,验证和计算的逻辑会放在Domain Model中。与Transaction Script将所有逻辑放在一个函数里不同,在Domain Model中,每个对象只负责自己相关的那一部分逻辑。Domain Model的价值是一旦你掌握了它,它提供了很多种管理不断增长的复杂逻辑的方法,如增加不同的策略对象。Domain Model的复杂性来源于使用上的复杂(新手需要学习的时间,思维的转换)以及数据源层的复杂(领域逻辑越复杂,数据库映射也越复杂)。
第三种选择是使用Table Model模式。Table Model模式适合与Record Set一起使用。Table Model看起来像是上面两者的一个折中,围绕着数据表来组织领域逻辑比起Transaction Script来说更为结构化,也更容易找出并排除重复代码,并且可以使用Domain Model中用来得到更好的结构的方法,如继承,策略等OO的模式。最大的好处就是它可以和系统的其他部分很好的进行配合,很多GUI的环境都建立在SQL查询的结果之上,这些结果通常用Record Set保存(如.NET中的数据绑定),而Table Model也是在Record Set上工作的。
做出抉择
对于简单的领域逻辑,Domain Model没什么吸引力,因为理解它的成本和数据源层点的成本显得太高了,然而,随着领域逻辑的复杂性的增加,其他的几个模式的成本程指数上升,而Domain Model是线性上升的。
对Domain Model熟悉的开发团队可以降低初始的成本,但不会降到和其他两个一样低,因为它的数据源层比较复杂。
Table Model吸引力的强弱很大程度上取决于你使用的开发环境对Record Set基本架构的支持程度,如.NET就支持非常好。
这三种模式并不是排他的,事实上,混合使用的情况是很常见的。
服务层(Service Layer)
常见的管理领域逻辑的方法是将它分成两层。服务层建立在Domain Model或Table Model之上,Transaction Script因为太简单了而不需要服务层。表现层完全通过服务层与领域层交互,这使它显得像是一组API。
服务层也是放置事务管理,安全管理的好地方。通常使用文件来配置这些信息,但是在.NET中使用自定义熟悉也是一个非常好的方法。
当你想到服务层的时候,一个关键的问题是在里面放多少的逻辑。最少的情况下,服务层就是一个facade模式的体现,提供了一组易于使用的API,并可以提供了事务管理和安全管理。另一个极端的情况下,大部分的逻辑都放置在服务层中,下次的领域对象非常的简单,如果下层是Domain Model,你将可以使用一个简单的数据源层,如Active Record。两者的折中,controller-entity,这里的关键点是将特定的事务或者用例放到Transaction Script中(通常将其称为controller,注意controller有很多种,如后面会说到的Model View Controller和Application Controller),这里作者将其称为user-case controller,相对于那些用于多个用例的方法,它们在领域对象中,称为entities。
作者建议,如果需要的话,就使用一个最“瘦”的服务层。