请问这种情况应该用什么模式？
谢谢！！！
谢谢！！！
我现在的做法是,根据表结构可以生成一个DAO和valueBean,当表结构变化时重新生成DAO和valueBean,其他部分不用改;
>有的构造与此表字段映射的对象，作为一个value object,
在某些情况下我的做法是create view,以映射原表的一些字段。这样原表的变化不会影响view的变化。
另外，我感觉表结构和entity虽然密切相关但不是一个概念的东西。for example,account表可能包含账户基本信息以及资金信息，但从entity概念上讲，account表包含了2个entity:账户实体和资金实体；另一方面，一个entity的数据可能分散在多个表中。例如"资金实体"的数据可能分存在account表的某些字段以及interest(利息)表中，account表和interest表通过foreign key关联。
如你所说增加一个字段的情况,我认为总能把这个字段归结为是哪个实体的属性，从而修改的是这个entity的相关实现，其他entity不用修改。
这不是使用什么design pattern的问题。在design pattern之前还有软件结构的更基本的原则。不管用不用design patten,基本原则都需遵循。
--欢迎参与讨论
在没有JDO支持下，你可能手工自己来处理了，尽量设计数据库时遵循粒度细化的原则，这样，修改起来牵动就小了。
to blues,
你可以参考一下ofbiz的view-entity的做法, 如果是分散在多个entity里面的数据, 可以用一个虚拟的view-entity来实现.
1、你用了o／r mapping
2、你的表结构添加了字段，那么对应的mapping java文件就需要重新修
改（虽然可以生成）。
3、无论mapping文件是否一定需要重新生成，但是对应client程序肯定需要修改，有没有什么办法修改的少点。
请问，你是这个意思吗？
在jbuilder中查找引用就可以找到吧
to blues:
>这些程序的作用有的在系统初始化时将此表中的数据先放进内存，以加快速度
我现在的做法是,根据表结构可以生成一个DAO和valueBean,当表结构变化时重新生成DAO和valueBean,其他部分不用改;
但是假如另一个程序要构造valueBean对象，现在由于字段变化， 这个程序的构造方法也得改变，所以其他部分还是得改动
>有的构造与此表字段映射的对象，作为一个value object,
在某些情况下我的做法是create view,以映射原表的一些字段。这样原表的变化不会影响view的变化。
做个view是假设这个表增加的字段对程序无影响，所以可以继续使用原来的view,但现在这些字段我必须在程序中增加逻辑处理
你应该知道opensource有很多自动生成原代的工具。比如Karapan Sapi 就是生成DAO,facade,struts，sql什么的工具。你把字段放进去一生成就OK了。
>做个view是假设这个表增加的字段对程序无影响，所以可以继续使用原来的view,但现在这些字段我必须在程序中增加逻辑处理
我还是认为不是设计模式的问题。如果是这种情况，那就是entity/业务逻辑发生变化，我们能做的是这个业务逻辑的变化与其他部分隔离开，就非常好了。这实质上还是软件设计中的“低耦合”原则。如果想什么都不变化，不太可能。
另外，关于valueBean变化的问题：在另外一个design pattern newsgroup（我忘记了）中曾有很多人讨论了"value of value object",认为既然一个value Object发生变化会导致从GUI到DAO一条线的修改，何不干脆用HashMap来代替valueObject。我不同意这个观点。使用valueObject的前提是必须明确地定义输入参数是什么，才能构造出合理的valueObject作为参数对象。所以如果valueObject发生重大变化，这一条线的修改不能缺少。--问题是如果valueObject经常发生变化，那就是entity设计的有问题。
>>使用valueObject的前提是必须明确地定义输入参数是什么<<
明确地定义输入/输出接口，也是比使用设计模式更重要的软件原则。你说呢？
谢谢.