zoukankan      html  css  js  c++  java
  • 企业应用架构模式阅读笔记3

    领域逻辑模式(领域逻辑设计相关)

    领域逻辑通常有三种方法:事务脚本、表模块、领域模型。在可以表模块或者领域模型的系统中,通常会再细分一个服务层,对于事务脚本能够实现系统,通常没有必要划分服务层了。如果在开发环境(visal studio,.Net)拥有大量记录集工具的环境下,使用表模块还是很吸引人的。

    1 事务脚本

    基于的思想:大多数企业的应用都可以被看作是一系列的事务,一个事务可能将某种信息看作是以特定方式组织的,然后另一事务会改变他,

    事务逻辑脚本将所有的事务逻辑组织成单个过程,在过程中直接调用数据库,或者用一个简单的数据封装器。每个事务都由自己的事务脚本,尽管事务间的公共子任务可以被分解为多个子程序。

    特点:许多事务脚本的设计中都有直接操作数据库的操作,有些把SQL语句直接放到数据库中。

    *评论:

    此处作者的事务脚本的概念在是,在程序编码当中,在一个或者几个方法中进行的直接操作数据库获取数据,进行判断逻辑、并回写数据库进行持久化的操作。这些操作为了完成某些业务,没有特殊的组织,一般没有经过精心设计的程序都可以归为事务脚本阶段。这是从编码风格角度来说的。

    在此,可以基于事务的思想,可以提出其它优化方法:

    1〉 使用数据库的存储过程来实现某些事务过程。书写方便,执行效率高,而且易于修改(不怕规则变动了)。目前我们的MIS系统中通常使用这种方式,但是,如果规则多了,事务脚本太多,管理不方便,而且,许多小的操作,不是频繁操作数据库的事务规则用数据库脚本就不合适了。

    2〉 基于《GOF设计模式》中 Command模式,将事务脚本组织起来,方便调用和管理。

    3〉 基于《GOF设计模式》中interpreter模式,将自己的脚本抽取为领域规则,使用自己的规则解释器去解释这个规则,最终形成自己的“领域标签”,终极模式是形成类SQL的规则语言。目前有些成熟的产品已经形成了自己的领域规则,并有自己的规则编写器,这样程序的二次开发问题能解决好多。软件产品中使用这个方法可以降低维护成本及解决产品定制问题,但是在项目中就不太方便了。

    2 领域模型

    基于的思想:如果领域逻辑规则太复杂了,就需要使用面向对象的方法来解决这个问题。面向对象将自然界的物体都表示为属性(数据)和操作,因此足以表达负责的逻辑。但是,映射到数据库比较困难,通常使用活动记录或者O/RM产品。

    EJB和POJO(plain of java object 普通java对象),在java中,如果领域逻辑比较复杂涉及到继承等操作,建议使用POJO,只有表结构与对象比较类似的情况下,使用ejb.

    基于领域模型或面向对象的参考书有:[Larman],[Flower AP],[Hay],[Martin and Odell]。

    3 表模块

    表模块是用一个类对应数据库中一个表来组织领域逻辑,而且使用单一的类来包含对数据进行的各种操作。它与领域逻辑的主要区别在于,如果有许多订单,领域模型使用多个类来处理订单而表模块使用单一的类来处理所有订单。

    表模块的长处是允许类和数据绑定在一起,可以充分利用关系数据库的优点。表模块看起来和常规的对象很象,但关键区别在于它没有标识出来所代表的常规对象。

    表模块可以是一个实例也可以是一个静态方法的集合。

    表模块的入口:表模块封装的是一个记录集,那么形成记录集的入口通常有两个,一个是在构造函数或者初始化入口中使用查询语句,另一种就是在入口中传递一个表数据(如recordset),这样的优点是封装了数据的生成,这个表模块可以面对多个数据源,并且你可以不用数据库就测试领域逻辑。缺点是多增加了一个用来生成数据的类。

    比较重要的是,此处的表模块并不是必须针对每一个数据库物理表创建一个表模块,其更多的是针对一个虚拟表结构(如物理视图或者一个查询语句)创建模块。创建表模块。

    如果使用表的结构与对象结构比较类似,则在领域模型中可以使用活动记录来解决,如果程序中有一个公用的表的结构,实际开发中,人们多倾向于使用表模块的方式来解决问题,比如微软平台中有一个ADO很好的封装了表,因此在微软的平台中,多使用表模块,而在Java中则没有这点条件,所以java中使用领域模型的比较多。

    在微软.net平台中,尽管使用无类型的表模块更能够实现平台无关性,但是有许多实例可以证明使用.net强类型数据集更好。

    4 服务层

    在领域模型中,通常可以再划分出来一个服务层,服务层在领域模型之上,封装了领域模型的实现。服务层定义了系统应用的边界和从客户角度看到的各种操作的集合。

    业务逻辑的分类:服务层是一种组织业务逻辑的模式,通常将业务逻辑分为两类,应用逻辑和领域逻辑,领域逻辑解决领域问题,应用逻辑与应用的职责相关,通常解决工作流、应用集成的问题。如果应用逻辑与领域逻辑分离,则能是领域逻辑更好的复用。

    实现方法:服务层可以只是定位到系统操作的集合,这样只是提供接口对外调用,没有复杂的逻辑即领域外观法,领域逻辑也可以提供操作脚本的方法,将数个操作脚本组成一个类,命名为**服务。

  • 相关阅读:
    Map与实体之间转换
    letsencrypt 免费SSL证书申请, 自动更新
    spring接收json格式的多个对象参数(变通法)
    controller函数中参数列表使用多个@RequestBody
    经典网页设计:30个新鲜出炉的扁平化网站设计《上篇》
    使用 iosOverlay.js 创建 iOS 风格的提示和通知
    字体大宝库:设计师必备的优秀免费英文字体
    RandomUser – 生成随机用户 JSON 数据的 API
    Salvattore:CSS 驱动的 jQuery Masonry 插件
    赞!jsPDF – 基于 HTML5 的强大 PDF 生成工具
  • 原文地址:https://www.cnblogs.com/123456www/p/13054329.html
Copyright © 2011-2022 走看看