请问这种情况应该用什么模式?

我有一个表,有几个维护这个表的程序,这些程序的作用有的在系统初始化时将此表中的数据先放进内存,以加快速度,有的构造与此表字段映射的对象,作为一个value object,等等。现在由于业务逻辑变化,需要在这个表中加一个字段,于是维护这个表的几个程序都得改动,请问大侠们有什么模式能解决这个问题,使得改动能集中在一个地方??
谢谢!!!

>这些程序的作用有的在系统初始化时将此表中的数据先放进内存,以加快速度
我现在的做法是,根据表结构可以生成一个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试图解决的问题,因为我们程序语言实现了对象化,但是数据库还是关系型的,所以在对象和关系直接存在一个映射:O/R Map,如果我们使用JDO技术,就可以完全用对象组织了。

在没有JDO支持下,你可能手工自己来处理了,尽量设计数据库时遵循粒度细化的原则,这样,修改起来牵动就小了。

可以使用dynamic value object, 写VO的定义文件, 通过统一的delegator调用, 这样如果增加, 修改字段就可以只用修改定义文件, 而不用修改代码.

to blues,
你可以参考一下ofbiz的view-entity的做法, 如果是分散在多个entity里面的数据, 可以用一个虚拟的view-entity来实现.

我不只你问的可是这个意思:
1、你用了o/r mapping
2、你的表结构添加了字段,那么对应的mapping java文件就需要重新修
改(虽然可以生成)。
3、无论mapping文件是否一定需要重新生成,但是对应client程序肯定需要修改,有没有什么办法修改的少点。
请问,你是这个意思吗?

我想他的意思肯定是希望能够快速定位到需要修改的client端的程序,也就是引用了此value object的地方吧,
在jbuilder中查找引用就可以找到吧

这么多大侠回复,实在受宠若惊!多谢了!现对blues兄的见解有点疑问,各位看是否如此。
to blues:
>这些程序的作用有的在系统初始化时将此表中的数据先放进内存,以加快速度
我现在的做法是,根据表结构可以生成一个DAO和valueBean,当表结构变化时重新生成DAO和valueBean,其他部分不用改;
但是假如另一个程序要构造valueBean对象,现在由于字段变化, 这个程序的构造方法也得改变,所以其他部分还是得改动


>有的构造与此表字段映射的对象,作为一个value object,
在某些情况下我的做法是create view,以映射原表的一些字段。这样原表的变化不会影响view的变化。
做个view是假设这个表增加的字段对程序无影响,所以可以继续使用原来的view,但现在这些字段我必须在程序中增加逻辑处理

呵呵,这种问题总是很郁闷。如果很懒的话,你就在建表的时候多留出几个字段吧,呵呵,开个玩笑。

你应该知道opensource有很多自动生成原代的工具。比如Karapan Sapi 就是生成DAO,facade,struts,sql什么的工具。你把字段放进去一生成就OK了。

to rumenzhe:
>做个view是假设这个表增加的字段对程序无影响,所以可以继续使用原来的view,但现在这些字段我必须在程序中增加逻辑处理

我还是认为不是设计模式的问题。如果是这种情况,那就是entity/业务逻辑发生变化,我们能做的是这个业务逻辑的变化与其他部分隔离开,就非常好了。这实质上还是软件设计中的“低耦合”原则。如果想什么都不变化,不太可能。

另外,关于valueBean变化的问题:在另外一个design pattern newsgroup(我忘记了)中曾有很多人讨论了"value of value object",认为既然一个value Object发生变化会导致从GUI到DAO一条线的修改,何不干脆用HashMap来代替valueObject。我不同意这个观点。使用valueObject的前提是必须明确地定义输入参数是什么,才能构造出合理的valueObject作为参数对象。所以如果valueObject发生重大变化,这一条线的修改不能缺少。--问题是如果valueObject经常发生变化,那就是entity设计的有问题。
>>使用valueObject的前提是必须明确地定义输入参数是什么<<

明确地定义输入/输出接口,也是比使用设计模式更重要的软件原则。你说呢?

cc,你好,我初看了一下karapan,不知道DAO的连接应该在什么地方设置的,能提示一下吗?
谢谢.