Rich Domain Model In Java ORM

其实做web应用应该很开心了。
如果涉及到remoting或者webservice,那种包含持久化能力(不论是显式编程的还是通过配置方式动态增强)的所谓rich domain model就是一个梦魇。
从spring的角度来看，一个组件是不是暴露为webservice或者其它别的远程访问协议，基本上可以通过配置做到，而组件代码本身是不预知的。但是，一旦用到了rich domain object,特别是动态增强型的rdo，那么为了顺利地远程访问，dto就变成不可缺少的了,因为在client端没有办法动态增强出rdo这样的一个类来。而一旦用到dto,各个环节上的重复性劳动马上大量增加。
就这个方面来说，.net下的dataset在java的世界内还没有匹配物，虽然怎么看怎么别扭，但通过remoting/webservice愣是能把整个填充过的各个表及其关系给方便而又彻底的序列化过去。实现离线操作和续弦。与之相比，hibernate的detached obj只是一个只能用于进程内传递的实现，根本无法跨越边界。
所以现在特烦那种带有持久化逻辑的rich domain obj.

Hosting Based Interfacing 正是为了解决类似问题的, 把繁复的远程调用模式实现的功能, 封装到 Task Agent 对象中, 发送到 RDO 原生的环境去执行, 只返回必要的简短结果数据. 更进一步的是客户端也提供一个Hosting环境, 这样发送到服务器的 TA 对象远程执行过程中也可以回馈可在客户端执行的的 TA. 这个架构比SOA的性能要高得多, 同时也不需要维护WebService接口, 可以专注在 RDO 和 TA 上.

但是毕竟这种方式引入了TA，而且某种意义上的dto也不可避免，尤其是在复杂数据的传输上。
我觉得这里的问题的最简单的办法是在c/s接口中传递不包含持久化逻辑的rdo,采用三个部分的方式,common/service/client三分，common中包含这些rdo的定义，client和service共同import这些common定义，service中独立实现rdo的持久化，client可以直接调用持久化无关的domain logic.
按照这个方式，ibatis是最直接的。只不过在复杂关系的序列化中会耗费大量的资源。

其实做web应用应该很开心了。
如果涉及到remoting或者webservice,那种包含持久化能力(不论是显式编程的还是通过配置方式动态增强)的所谓rich domain model就是一个梦魇。
从spring的角度来看，一个组件是不是暴露为webservice或者其它别的远程访问协议，基本上可以通过配置做到，而组件代码本身是不预知的。但是，一旦用到了rich domain object,特别是动态增强型的rdo，那么为了顺利地远程访问，dto就变成不可缺少的了,因为在client端没有办法动态增强出rdo这样的一个类来。而一旦用到dto,各个环节上的重复性劳动马上大量增加。
就这个方面来说，.net下的dataset在java的世界内还没有匹配物，虽然怎么看怎么别扭，但通过remoting/webservice愣是能把整个填充过的各个表及其关系给方便而又彻底的序列化过去。实现离线操作和续弦。与之相比，hibernate的detached obj只是一个只能用于进程内传递的实现，根本无法跨越边界。
所以现在特烦那种带有持久化逻辑的rich domain obj.

加载到内存里的对象图, 通常都是按对象相关性组织的, 这样才是Domain Model. 它应该直接保存着指向那100条数据的集合, 用到的时候是直接遍历这100条数据, 而不是全部的1000万记录. 有谁会设计一个Domain Model必须把一张表的全部数据, 不管相关不相关的, 都先加载到内存再说的吗.

SQL查询的时候才需要面对一张表的全部1000万条记录; 如果通过Domain Model处理, 也需要从一张表里的全部记录筛选自己相关的部分, 那么首先这不是一个像话的Domain Model, 其次如果不得不做这种事儿, 确实还不如用SQL.

问题是系统的复杂性往往就存在于如果从1000万条记录中取100条记录，这里面可能有很多业务逻辑，有很多来自不同aspect的考虑因素，它们往往会因为性能因素而用存储过程或者加入hint的view来实现，这决不是在java虚拟机里面遍历能搞定的。如果不能利用java语言特性来解决这种复杂性，从而体现出比直接写SQL或存储过程更好的可维护性，那么把数据组织成object的意义何在呢？

所以，即使有ruby那样的动态语法，还是回避不了这个问题：因为性能而必须要构造复杂的SQL在数据库端完成查询或更新，而domain object本来是被期望能用来屏蔽这样的一些复杂性的。

这里Domain Model可以做的就是每增加一个符合条件的记录, 就建立起关联, 随之增加到相关对象的列表里去; 列表里的对象被删除或者变得不符合条件以后就删除关联, 随之从列表里清除出去. 作为对象行为, 这些业务判断在适当的时机被触发, 进而维护关联的正确性. 其实功能上就相当于SQL触发器, 但是作为object就可以获得面向对象编程的种种好处了. 同时维护出来的也是可以直接遍历的内存对象图, 而不是每次都得通过检索来访问的SQL记录了.

最终的结果就是你想要这100条记录的时候它们已经在一个内存集合里了, 而不是每次用到都必须去重新过滤出来.

而TOB对这个模式有进一步的支持, 那就是这个内存集合在没有被应用使用时可以被交换出内存, 以后再需要访问的时候可以背地里按原样恢复回来, 对应用完全透明.