摘要:
•Gateway入口 ◦一个封装了对外部系统或资源访问的对象. ◾OO系统中,也需要访问一些不是对象的事物,DB表,XML,事务. ◾这些外部资源的API很复杂. ◾入口类对象将简单的方法调用转换成相应的特定API. ◦运行机制 ◾本质上是简单的包装器模式. ◾封装外部资源,创建一个简单的API,并用入口将对该API的调用转移到外部资源上. ◾它可以作为使用服务桩的极佳位置. ◾应尽可能保持入口简单.复杂的逻辑应该放在入口的客户中. ◾有时需要多个对象来构造入口 ◾常见的:一个后端,一个前端. ◾后端封装对外部资源操作的代码,... 阅读全文
摘要:
Client Session State 客户会话状态.在Client端保存会话状态.运行机制Client在每次请求时会把所有的会话数据传给Server,Server在响应时把所有的会话状态传给Client.可以是完全无状态的Server.通常使用可序列化的DTO对象来传递数据.在HTML中,可选的是:URL参数,表单的隐藏域,Cookie.使用时机支持无状态的Server对象.从而提供了最大的集群性能和容错恢复.适合于小数据量.当数据量大时,保存和传输会有较大的延迟.安全问题.所有送到客户的数据都很容易泄露或被篡改.而加密又会影响性能.会话标识号一般使用Client会话状态.Server S 阅读全文
摘要:
用一个锁Lock一组相关的对象有时,需要按组来修改多个对象.这样,在需要锁住其中一个的时候,必须连带地将其他的对象都上锁.为每一个对象都加上一个锁是很繁琐的.粗粒度锁是覆盖多个对象的单个锁.简化了加锁行为.且不必为了给它们加锁而加载所有对象.运行机制为一组对象建立一个控制点.使用乐观离线锁让组中每个对象共享一个版本号来建立一个控制点.增加这个版本号时,就成为一个锁住组中所有对象的共享锁.需要在模型中指定该组的每个对象.共享的悲观离线锁要求组中每个对象共享某种锁标记.通过这个锁标记来锁住它们.一个共享的版本对象就是最好的锁标记.作为数据修改的基本单位的一组相关对象可看成一个aggregate聚集 阅读全文
摘要:
每次只允许一个业务事务来访问数据,以防止并发业务事务中的冲突.离线并发处理通常会出现多个业务事务操作同一数据.最简单的办法是为整个业务事务保持一个系统事务.但是事务系统不适合于处理长事务.首选乐观离线锁.而悲观离线锁,作为它的补充.从一开始就避免冲突.它要求业务事务在对数据进行操作前就必须获取该数据的锁.一旦开始了一个业务事务,就确信不会再提交时由于并发冲突而被迫回滚数据.运行机制决定使用哪种锁exclusive write lock独占写锁.写目的的会话数据时使用,当对数据的读取要求不高时.exclusive read lock独占读锁.仅是为了读目的时的数据.限制了并发性.read/wri 阅读全文
摘要:
通过冲突检测和(发生冲突时的)事务回滚,来防止并发业务事务中的冲突.通常一个业务事务的执行,会跨越一系列的系统事务.一旦超出了单个系统事务的范围,就不能仅依靠DB管理程序来保证数据一致性.乐观离线锁假设冲突的发生可能性很小.使多用户并发地对同一份数据进行处理成为可能.在同一业务事务中,进行预验证和对数据的修改.一个成功的预验证可以视为得到一个锁,来表示能够成功地完成对数据的修改.运行机制原理:通过检查在(业务事务)会话读取一条记录后,没有其它的会话修改该记录来保证数据的一致性.可以在任何时间获取该锁,但是它只在获得该所的系统事务过程中有效.系统事务中只有有对DB的修改,就需对每个变更成员申请该 阅读全文
摘要:
Remote Facade远程外观在OO模型中,存在很多规模小,且有小方法的对象.这些小对象会导致很多的对象间交互.在单一地址空间里,小对象没问题.但是,当在两个进程间做调用时,频繁的跨进程交互会造成性能开销.远程外观,减少远程调用的次数.建立在大量的细粒度对象之上,提供一个粗粒度的外观.不包括任何的领域逻辑.只是将方法转换到细粒度对象上.运行机制细粒度对象适合于解释复杂的逻辑.远程外观使用bluck accessor来使用一个getter/setter来完成在细粒度对象中的所有gettter/setter.单个远程外观,也可以作为多个细粒度对象的一个远程入口.远程外观的设计基于特定的客户需求 阅读全文
摘要:
MetaData Mapping元数据映射在MetaData中保存object-relation映射的详细信息.以表格形式定义映射,并可由通用代码来处理映射.运行机制MetaData中的信息如何以运行时Code的形式表现.Code Generation程序:输入是MetaData,输出是映射实现类的SourceCode.在编译前在构建流程中自动生成.应保证将它完全合并到构建流程中,且不应该手动编辑它.Reflective Program把方法/域视为数据.从MetaData文件中读入域和方法的名称,并用它们实现映射.性能慢,且会产生难以调试的代码.代码生成缺乏动态性,改变映射需要重新编译和部署 阅读全文
摘要:
使用将若干相似的类映射为单表,对拥有许多特殊数据的类使用具体表继承.对高层次使用类表继承,对低层次使用具体表继承.Single Table Inheritance在DB中将类继承层次设计为一个单表,表中各列代表不同类中的所有域.运行机制每个类负责把与之相关的数据保存在表的一行中.表中其它不相关的列留空.通过表中的Type字段来决定向内存中加载对象时,应该实例化那个类来创建该对象.可以直接使用类名称或者需要经过翻译的Code域.保存数据的代码可以由层超类负责.使用时机优点只需要关注一个DB表.获取数据时不必进行连接.对继承层次的重构(在父子之间挪动某个域)不需要修改DB.缺点DB表的列和对象的域 阅读全文
摘要:
Embedded Value把一个对象映射成另一个对象表中的若干字段.OO系统中会有很多小对象(DataRange,Money).而作为表在DB中毫无意义.默认想法是把一个对象保存为一个表.但是,将这些小对象,映射为该对象所有者记录中的若干字段.运行机制可以看做一种特殊的依赖映射.该值对象是一个依赖者对象.由所有者完成对依赖者的加载和保存.使用时机简单的值对象.由于没有ID.所以更新时不需要标识映射来同步.所以不需要DB表来对应.一般,只用在简单的依赖者上.只在一对一关联关系时,才使用.或者依赖者数量很少且固定时.如果想在SQL查询中使用依赖者值时,需要使用它.对于复杂的依赖关系(巨大的对象子 阅读全文
摘要:
让一个类为其子类(泛意上的)执行DB映射一些对象肯定会出现在另一对象的上下文中.此时,使用另一对象的Mapper来执行第一个对象的映射,来简化映射过程.运行机制在DB持久化时,依赖者类依赖于所有者类.每个依赖者只能有一个所有者.活动记录和行数据入口依赖者类的映射代码都写在所有者中.数据映射器没有依赖者的映射器类,在所有者的映射器中完成依赖者的映射代码.表数据入口根本没有依赖者类.在所有者中完成对依赖者的处理.通常,加载一个所有者时,会把相关的依赖者加载.当该相关加载耗费很大时,会使用延迟加载.依赖者没有标识域.也就不用存储到一个标识映射中.不能通过ID由查找方法加载.从而没有依赖者的查找器,而 阅读全文