Domain logic approachs

领域逻辑组织能够分为三种主要的模式:事务脚本(Transaction Script)、领域模型(Domain Model)和表模块(Table Module)”算法

1.transaction script(事务脚本)数据库

概述:数据结构

不少企业应用能够当作一系列的事务,每个事务能够经过使用一个Transaction Script来处理。app

用法:dom

 使用Transaction Script,咱们能够专一于处理好每个事务,而没必要考虑其余事务的影响,所做的就是获得输入,查询数据库,处理事务,保存结果。        Transaction Script能够有两种方法组织成类。一种是将同一领域的几个Transaction Script放在一个独立的类中;另外一种是采用Command模式,将每个Transaction Script组织成一个Command基类的子类;固然,也能够不要组织成类,而使用全局函数的方式,可是类的方式更易于隔离数据。函数

适用状况:性能

Transaction Script最大的优势和缺点,都是在于它的简单性。优势是代码的简单易懂,运行效率也不错;缺点是极可能出现代码重复,固然这个能够经过重构来减轻,更重要的是,随着企业事务复杂性的增长,Transaction Script就会变得力不从心。        Transaction Script下的开发有如下特征:对象类只包括数据,不包括任何事务相关的算法,每每就是数据库中表结构的类化;调用的Sql语句经常在Transaction Script核心函数中出现,固然这个是很差的设计,应该使用好比Table Data GateWay等模式,将Sql语句封装在wrapper中,来进行数据库交互,而核心函数直接访问wrapper的方法来进行事务处理。设计

 事务脚本组织成类的方法:对象

  将数个事务脚本放在一个类中,每一个类围绕一个主题将相关的事务脚本组织在一块儿。(最经常使用)继承

  每个事务脚本对应一个类,此时需使用命令(Command)模式。使用时机

  事务脚本胜在简单。对于只有少许逻辑的应用程序来讲,使用这一模式很是天然,不管在性能上仍是理解上都不会带来太大开销。

  当业务逻辑愈来愈复杂时,该模式就会愈来愈难以保持良好的设计。它特有的问题是事务之间的冗余代码。

2.domain model(域模型)

概述:

域模型是抽象系统,描述知识,影响或活动领域的选定方面(域)。而后,该模型可用于解决与该域相关的问题。域模型表示与须要在软件中建模的域相关的有意义的现实世界概念。这些概念包括业务中涉及的数据以及业务与该数据相关的规则。

域模型一般使用域的词汇表,从而容许将模型的表示传达给非技术利益相关者。它不该该指任何技术实现,例如正在设计的数据库或软件组件。

用法:

域模型一般被实现为层内的对象模型,该层使用较低层的层来持久化而且将API“发布”到更高层的层以得到对模型的数据和行为的访问。

在统一建模语言(UML)中,类图用于表示域模型。

 

3.table module(表模块)

概述:

Table Module是处理一个数据表或者数据视图全部行的业务逻辑的一个单独的实例。    通常的,Domain Model等传统面向对象模式都创建在对象/身份的基础之上,就是说好比一个员工类的实例就对应着一个特定的员工,这样咱们能够执行员工操做,获取员工信息等。这些模式的很差之处在于很难和关系数据库造成好的接口,致使咱们要做大量工做用于处理数据在业务层和数据库这两个表现彻底不一样的层次之间的传递。    Table Module则否则,它对于数据库中的每一个表创建一个类的实例,用来操做该表中的数据。

用法:

Table Module模式使得咱们能够打包数据和它们的行为,并同数据库保持很好的联系。它经常做为面向表的后台数据结构,而表状的数据通常的是Sql语句调用的RecordSet返回值。    Table Module便可以使类的单独实例,也能够是类的一组静态函数。采用实例的方式给咱们更大的好处,便于经过一个存在的RecordSet来初始化,也很容易的经过继承等方式进行扩展。    Table Module模式能够经过厂模式来实现请求,另外的方法是经过Table Data Gateway,很差的是引入了Table Data Gateway类和机制,好的方面是咱们能够只使用一个Table Module了,对于不一样的数据源,采用不一样的Table Data Gateway就能够了    Table Module使用方法是:首先经过Table Data Gateway把数据装成RecordSet,而后以其为参数建立Table Module,经过Table Module来处理业务逻辑,并把修改的结果传回数据库。中间的过程当中,RecordSet数据一直在内存中,而没必要返回数据库。    固然Table Module并不局限于表,表/视图/Sql查询结果等均可以应用此模式

适用状况:

Table Module基于面向表的数据,并且它必定是把数据结构放在整个代码的中心。面对一个复杂的业务逻辑,它不能提供足够的实例-to-实例的能力,在处理多态上也存在不足,这时咱们仍是应该采用Domain Model,Domain Model+Active Record也能够处理表状的数据。    Table Module在COM应用中比较常见,这是由于微软的ADO库提供了一个很好的机制,使用RecordSet来处理数据库的数据。

相关文章
相关标签/搜索