领域逻辑模式

Transaction Script

• 使用过程来组织业务逻辑,每个过程处理来自表现层的单个请求.
• 运行机制
  • 尽可能将其放置于与表现层和数据源层隔离的类中.
  • 为了便于修改和测试,不能调用任何表现层逻辑.
  • 组织成类
    • 一个类,围绕一个主题将相关事务脚本组织在一起.
    • Command模式.一个事务脚本对应一个类.
      • 优点:允许在运行时以对象的方式来操控脚本类的实例;便于解决线程相关问题.
  • 使用时机.
    • 胜在简单.
    • 当业务逻辑复杂时,很难保持良好的设计.会出现事务之间的冗余代码的问题.
• Domain Model

• 合并了行为+数据的领域的对象模式.创建了一张由互联对象组成的网.
• 运行机制
  • 创建一个完整的由对象组成的层,来对目标业务领域建模.
  • 一些对象模拟业务活动中的数据,一些对象扑捉业务使用的规则.
  • 整合了数据和处理,从而紧密地聚合了数据和数据之上的操作.
  • 两种风格
    • 简单领域模型:每一个数据库表对应一个领域对象.所以类似于数据库设计.
    • 复杂领域模型:使用继承,策略和模式,由互联的细粒度对象组成的复杂网络.
    • 简单型的容易映射到数据库,使用活动记录.而复杂型的需要使用数据映射器.
  • 由于业务的易变性.修改,构建和测试对于领域层是重要的.所以应使用分层将该层和系统其它部分之间保持最小的耦合或依赖.
  • 内存和对象
    • 面向对象的数据库的优点在于能够管理对象的导入,可以使对象在内存和磁盘之间迁移.
    • 可以自己完成.一次会话中,将相关的对象组成的一个对象图导入到内存中.其中,由数据库映射对象决定导入那些对象.
    • 当希望多次服务器调用都使用同一对象图,就必须将服务器的状态保存在某处.
  • 缺点
    • 领域对象过于臃肿.对象中充斥着许多只在特定用例中才会用得到的职责,从而过于庞大.
    • 可以分离这些特殊职责,但是会带来冗余的代码.
    • 一般做法是,不要分离,而把职责放在原本应该存在的类中.只有当对象臃肿发生时才修正.
• 使用时机
  • 使用领域模型时,首选的数据库交互方式为数据映射器.它有助于保持领域模型对数据库的独立性.
  • 应考虑设立一个服务层,从而给领域模型一个更清晰的API.
  • 大量运用细粒度对象:多个类交互完成即使很简单的行为.好处在于将行为封装在相关对象中避免了冗余的代码,也减弱了不同对象间的耦合.
  • 通过从一个对象到另一个对象的连续传递可以将行为传给应该处理它的对象上,同时消除了条件判断行为.
  • 使用策略创建好对象时,相当于设置好了决策路径.
  • 相似的条件判断语句提取到对象结构本身中,复杂性从算法迁移到了对象间的关系上.
  • 领域模型的要点在于隐藏数据库的存在.
• Table Module.

• 处理某一数据库表或视图中所有行的业务逻辑的一个实例.
  • OO的关键思想:将数据和对该数据操作的行为绑定在一起.
  • 传统的OO方法基于拥有标识符的对象(领域模型).每一个类实例对应一个特定的对象(雇员).
  • 其问题是与数据库的衔接.
  • 表模块以一个类来对应数据库中的一个表来组织领域逻辑,并且使用单一的类实例来包含将对数据进行的各种操作程序.
  • 区别,如果有多个订单,领域模型对每一个订单都会有一个对象,而表模块只用一个对象来处理所有的订单.
• 运行机制
• 优点:封装了数据和行为,同时充分利用关系数据库的优点.
• 其本身没有标识符来标出它所代表的实体对象.当需要针对某一个特定(雇员)对象进行操作时,需要传入标识符(主键).
• 表模式会与面向表的后端数据结构一起使用.
  • 以列表形式排列的数据通常是某个SQL调用的结果,它们被置于一个记录集中,用来模拟一个SQL表.
• 常见的是每个表使用一个表模块.当然也可以在查询或者视图之上使用表模块.
  • 表模块的结构,更多的是由APP能识别的虚拟表所决定(例如,视图和查询).
• 表模块可以是一个实例,或者一个静态方法集合.
  • 使用实例的优点是可以进行初始化,从而将其和某个已存在的记录集联系起来.同时还可以使用继承来添加额外的行为.
• 表数据入口.
• 优点
  • 可以在来自不同数据源的数据上使用单个表模块(对每一个数据源使用不同的入口).
  • 无需数据库就可以测试表模块,只需在内存中创建一个记录集.
• 过程
  • 使用入口将数据汇集到一个记录集中.
  • 然后以该记录集为参数创建一个表模块.
  • 表模块在记录集上应用业务逻辑,然后将修改后的记录集传递给表现层显示.
  • 在GUI中修改后,数据集在存入数据库钱会先在表模块中进行校验.
• 使用时机
  • 表模式依赖于以表方式组织的数据.当使用记录集存取表数据时应使用该模式.　
  • 表模式:较易于与下层面向表的数据结构整合的能力;领域模型:处理复杂逻辑的能力(实例间建立直接关联,多态).
• Service Layer

• 通过一个服务层来定义应用程序的边界,在服务层中建立一组可用的操作集合,并在每个操作内部协调应用程序的响应.
  • 封装了应用的业务逻辑,事务控制,操作实现中的响应协调.
• 运行机制
• [业务逻辑]的种类
  • 服务层是一种组织业务逻辑的模式(类似于事务脚本和领域模型).
  • 分为
    • 领域逻辑.与问题领域有关.
    • 应用逻辑.与应用的职责有关.即"工作流逻辑".
  • 在领域模型中,将应用逻辑置于纯粹的领域对象中,不便于在不同的应用之间重用领域对象.
  • 服务层把每种业务逻辑分解成一个单独的层,使得纯粹的领域对象类可以在不同应用之间更好地重用.
• 实现方法
• 领域外观.以领域模型之上的瘦外观集合方式实现.所有业务逻辑均由领域模型实现.建立的是客户层和程序交互的边界和操作集.
• 操作脚本方法.
• 服务层由一组复杂类组成,这些类直接实现应用逻辑.但是将领域逻辑委托给封装好的领域对象类.
• 以脚本的方式实现客户所能使用的操作,数个脚本组成一个类.
• 一个类定义与摸个主题相关的逻辑.每个类组成一个应用程序服务.
• 服务层由应用程序服务类组成.
• 识别服务和操作
  • 由服务层的客户的需求来决定服务层的边界上应提供的操作.排在第一位的是GUI.
• 使用时机
• 优点
  • 它定义了一个公共的应用程序操作集合,该集合可被各种客户使用.而且服务层在每个操作中都会协调应用的响应.
• 当业务逻辑只有一种客户(如GUI),或者用例响应并不涉及多个事务性资源时,就不需要服务层.