业务对象：利用对象模型把业务数据和业务逻辑分离开来。业务对象在最前端（客户端）和最后端（数据资源）都会进行业务数据形式的转化。业务对象的实现通常有两种方式：POJO + JDO 或者 Entity Bean + BMP/CMP。业务对象包含业务逻辑和业务状态。

J2EE系统中面向过程向面向对象转变有时甚至仅仅区别于最初的一念之差。没有什么是绝对的事情，如果业务非常简单，客户端通过浅浅的显示层，直接访问持久层、甚至数据资源存储中业务数据，整个过程中，其结构都是依据客户端所需数据的获取过程来完成的，是典型的面向过程的实现方式，没有什么不合理；但一旦情况复杂了，你也许希望在系统中设定一些核心的业务模型，让它们来驱动整个服务的提供和流程的运转，而不再是客户端无任何包装的需求，这时候兴许就变成了模型驱动下的面向对象行为。

?

复合实体：Composite Entity。结合本地entity bean和POJO，实现业务对象持久化。复合实体能够把一组相互关联的业务对象聚合为粗粒度的entity bean实现。业务对象被实现为父对象和从属对象，从属对象紧耦合与父对象，且无法独立存在或独立被访问、识别和管理。无论使用远程对象还是本地对象实现复合实体，都不应该直接把entity bean暴露给客户端，而应当封装在门面里面。

实际我们的项目中，给内容超市部分，封装了核心的API，而API的调用传值，都是通过复合实体——各种Event完成的。这是一个很好的例子，就算日后将API扩展成可远程调用的方法，性质并未改变。

脏数据标示器策略：对复合实体持久化的时候，如果能判断哪些从属对象是脏的，就可以提高持久化性能。

传输策略可以考虑单次传输整个复合实体，减少网络交互；可以结合脏数据标示器，只传输变化的部分；可以结合懒加载策略，只传输需要的部分。

?

传输对象：Transfer Object。跨层次传输多种数据元素。有一种简化远程对象和远程接口的方法是，把众多get/set方法合并成粗粒度的getDate和setData方法。我们通常希望传输对象是简单和可控的，因此粒度不应过细，细节应尽量屏蔽，对于接口的定义，应该尽少约束。

日后我们系统的API扩展必然面临着复合实体传输的情境，API的远程调用已渐渐变得广泛，比如JavaEye支持API调用，使用JSON作为数据形式；我们常用的Blog客户端也是遵从的简约的API规范开发的。

?

传输对象组装器：Transfer Object Assembler。复合传输对象的形式构建应用模型。从各种不同的业务组件和业务服务中聚合多个传输对象，并且最后把复合对象返回给客户端。最大的好处：减少了客户端和应用模型之间的耦合。对于不同的传输形式，就并不需要应用模型做任何的改变，搭配不同的传输对象组装器和传输策略即可。

系统的页面集成中涉及到的会话信息的传递，提供了几种策略，就涉及到SpringHTTPInvoker传输、OSCache传输、本地传输和void传输等相应的对象组装器。

?

值列表处理器：Value List Handler。执行查询、缓存结果，并让客户端遍历、选择查询结果。基本上相当于封装了一个游标，共客户端遍历操作，但是如果这个游标是远程的，注意可能造成巨大的性能消耗。

我们的系统中设计了一个类：PaginationSupport，用于分页，其角色便类似于值列表处理器。需要查询哪一块区域的数据集合，就传递相应的游标指令。

?

文章系本人原创，转载请注明作者和出处