企业应用架构模式 之 领域逻辑模式

领域逻辑的组织可以分为三种主要的模式：事务脚本，领域模型，表模块。 

面向过程的开发模式：事务脚本
         事务脚本是这样一个过程开发逻辑：从表示层获得输入，进行校验和计算处理，将数据存储回数据库中，以及调用其他系统的操作等。然后，该过程将更多的数据返回给表示层，中间可能要进行大量的计算来组织和整理返回值。基本的组织模式就是让每个过程对应用户可能做的一个动作。所以，我们可以将这一模式想象成一个动作或业务事务的教本。该教本可以拆分为不同的子过程，这些子过程可以在不同的事务脚本中共享。但是每个动作都由一个过程来驱动的。
         事务脚本的开发模式是基于过程的，所以它发挥不了面向对象开发语言的优势，尤其是在领域逻辑复杂性增加时候，缺点就显的更为明显。企业应用开发中，往往类似的业务很多，所以相似的动作不可避免，通常会使多个脚本包含某些相同的代码。通过将这些代码提取为公共的子过程可以部分的消除这种情况，但在很多时候，消除副本，检测副本都很困难。这使的应用程序没有清晰的结构，带来测试，修改，维护等等的不便。
         所以，事务脚本一般只用在简单的案例中，但是建议面向对象的开发人员，即使在简单的案例中也宁愿使用领域模型。虽然适应领域模型的思维方式比较困难，但是，一旦习惯了领域模型，从而受益终生。

面向数据集的开发模式：表模块
         表模块是处理某一数据库表或视图中所有行的业务逻辑的一个实例。表模块通过强类型或弱类型的数据集与对象结合使用，使用主键查询数据，是.Net中使用的很多的一种模式，主要使用主键、半对象化的操作数据。之所以说是半结构化，是因为所用的对象基本上只具有行为，通过传入参数执行特定的操作或者查询记录集，而几乎不承载任何数据。在.net中，这种模式因为其容易和UI进行绑定和交互，所以倍受欢迎。
         DotNet以及Delphi都提供了大量的数据感知组件，可以使用Rad的快速开发模式来开发基于DataSet，DataTable的企业级应用。这种开发模式其实就是基于表模式的。我们只要在界面上摆放一些数据感知组件比如DataGrid等，然后设定同数据源的连接，以及 连接的表，显示的字段，一个简单的程序就搞定了。
         面向数据集的开发模式非常使用于中小型的企业级应用开发，也是国内很多公司的开发模式。但是对于复杂的应用程序来说，业务逻辑的复杂程度会使该种开发方式显的力不从心。
         首先，使用RAD和数据感知组件，就使数据显示层和数据库表紧耦合，任何对数据模型的改变都会导致所有绑定到改动的表字段的数据感知组件的修改。这就是在Delphi开发中，很多开发者宁愿使用StringGrid以及ListView等数据非感知组件做数据显示控件的原因了。
         其次，从弱类型数据集中读取数据时，通常是根据字段名来获取字段的对象的值，比如DataTable["Name"].Tostring(),该方法是以字符串为索引来获得数据集中的字段值，所以如果字段名称写错了，错误也不会在编译期发现，只有在运行期报错，这就给排错带来困难。
         使用数据感知组件，意味着和数据库的特有特性的紧耦合。比如为了减少代码量和提高效率，经常需要使用一些数据库平台相关的特殊sql，或者将一些复杂的sql写成平台相关的存储过程，这样当向不同数据库平台移植时，需要重新编写大量的业务逻辑，这也就是企业级开发中，建议少用甚至不用存储过程的原因了【注意是企业级应用开发】。而面向对象的开发方式有一般基于面向对象的查询语言，比如Hibernate的HQL语言，具有一致性，更加容易实现数据库平台无关性，实现系统方便地迁移。
         基于数据集的开发模式难于应用继承，多态，设计模式等面向对象的开发方法，而且数据集对象不能包含自定义的操作。而领域模型则没有这样的障碍，开发的系统更加直观，更加容易维护。

面向对象的开发模式：领域模型
         在最坏的情况下，业务逻辑可能会变的极其复杂。此时，规则和逻辑描述了许多不同的用例和行为的变化。对象正是针对这种复杂性而设计的，面向对象的特性加上设计模式足以应对复杂的业务逻辑。
         企业级应用的信息载体是各种数据库，而数据库表是基于关系的，假如能够把关系数据表转化为对象，使得操作数据表如同操作对象一样灵活，消除对面向数据集的Sql的依赖，也就可以应对复杂的企业业务，该有多好啊！
         这也就是面向对象的开发模式：领域模型。领域模型创建了一张由对象组成的业务网。其中的每一个对象都代表某个有意义的个体，可能大到一个公司也可能小到订单的一行。
         面向对象的领域模型通常和面向关系的数据库模型类似，但仍然有许多不同。领域模型混和数据和处理过程，拥有赋值属性和复杂的关联，并且可以使用继承。
         所以，领域模型衍生了两种风格：简单领域模型和复杂领域模型。
         简单领域模型可以使用活动记录，即简单的单条数据记录和单个对象对应的模式，一个对象对应数据库中的一个表。
         复杂领域模型需要使用数据映射器，它可能使用继承、策略或者其他的设计模式，是一张由互联的细粒度对象组成的复杂网络，我们经常会看到：多个类通过交互来完成很简单的任务。复杂领域模型更适用于复杂的逻辑，但它到数据库的映射比较困难。
         领域模型的要点在于隐藏数据库的存在，转化业务操作为对象操作。
         ORM[对象关系映射]是现在流行的解决数据库转化为对象的思想，而Hibernate框架是其中的佼佼者。
         【注：活动记录和数据映射器都是企业应用架构模式。】