|
|
|
我有一个表，有几个维护这个表的程序，这些程序的作用有的在系统初始化时将此表中的数据先放进内存，以加快速度，有的构造与此表字段映射的对象，作为一个value object,等等。现在由于业务逻辑变化，需要在这个表中加一个字段，于是维护这个表的几个程序都得改动，请问大侠们有什么模式能解决这个问题，使得改动能集中在一个地方？？
谢谢！！！
|
|
|
|
|
|
Re: 请问这种情况应该用什么模式？
|
2003年05月13日 21:16
|
|
|
>这些程序的作用有的在系统初始化时将此表中的数据先放进内存，以加快速度
我现在的做法是,根据表结构可以生成一个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,基本原则都需遵循。
--欢迎参与讨论
|
|
|
|
|
|
Re: 请问这种情况应该用什么模式？
|
2003年05月14日 11:11
|
|
|
你这个问题正是目前热门技术JDO试图解决的问题，因为我们程序语言实现了对象化，但是数据库还是关系型的，所以在对象和关系直接存在一个映射：O/R Map，如果我们使用JDO技术，就可以完全用对象组织了。
在没有JDO支持下，你可能手工自己来处理了，尽量设计数据库时遵循粒度细化的原则，这样，修改起来牵动就小了。
|
|
|
|
|
|
Re: 请问这种情况应该用什么模式？
|
2003年05月14日 12:17
|
|
|
可以使用dynamic value object, 写VO的定义文件, 通过统一的delegator调用, 这样如果增加, 修改字段就可以只用修改定义文件, 而不用修改代码.
to blues,
你可以参考一下ofbiz的view-entity的做法, 如果是分散在多个entity里面的数据, 可以用一个虚拟的view-entity来实现.
|
|
|
|
|
|
Re: 请问这种情况应该用什么模式？
|
2003年05月14日 13:15
|
|
|
我不只你问的可是这个意思：
1、你用了o／r mapping
2、你的表结构添加了字段，那么对应的mapping java文件就需要重新修
改（虽然可以生成）。
3、无论mapping文件是否一定需要重新生成，但是对应client程序肯定需要修改，有没有什么办法修改的少点。
请问，你是这个意思吗？
|
|
|
|
|
|
Re: 请问这种情况应该用什么模式？
|
2003年05月15日 11:25
|
|
|
我想他的意思肯定是希望能够快速定位到需要修改的client端的程序，也就是引用了此value object的地方吧，
在jbuilder中查找引用就可以找到吧
|
|
|
|
|
|
Re: 请问这种情况应该用什么模式？
|
2003年05月15日 14:45
|
|
|
这么多大侠回复，实在受宠若惊！多谢了！现对blues兄的见解有点疑问，各位看是否如此。
to blues:
>这些程序的作用有的在系统初始化时将此表中的数据先放进内存，以加快速度
我现在的做法是,根据表结构可以生成一个DAO和valueBean,当表结构变化时重新生成DAO和valueBean,其他部分不用改;
但是假如另一个程序要构造valueBean对象，现在由于字段变化， 这个程序的构造方法也得改变，所以其他部分还是得改动
>有的构造与此表字段映射的对象，作为一个value object,
在某些情况下我的做法是create view,以映射原表的一些字段。这样原表的变化不会影响view的变化。
做个view是假设这个表增加的字段对程序无影响，所以可以继续使用原来的view,但现在这些字段我必须在程序中增加逻辑处理
|
|
|
|
|
|
Re: 请问这种情况应该用什么模式？
|
2003年05月16日 15:53
|
|
|
呵呵，这种问题总是很郁闷。如果很懒的话，你就在建表的时候多留出几个字段吧，呵呵，开个玩笑。
你应该知道opensource有很多自动生成原代的工具。比如Karapan Sapi 就是生成DAO,facade,struts，sql什么的工具。你把字段放进去一生成就OK了。
|
|
|
|
|
|
Re: 请问这种情况应该用什么模式？
|
2003年05月16日 19:45
|
|
|
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的前提是必须明确地定义输入参数是什么<<
明确地定义输入/输出接口，也是比使用设计模式更重要的软件原则。你说呢？
|
|
|
|
|
|
Re: 请问这种情况应该用什么模式？
|
2003年11月11日 16:01
|
|
|
cc，你好，我初看了一下karapan，不知道DAO的连接应该在什么地方设置的，能提示一下吗？
谢谢.
|
|
|
|
注册
登陆
.text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://my.poco.cn/fav/storeIt.php?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t)+'&img=http://www.h-strong.com/blog/logo.gif','keyit','scrollbars=no,width=475,height=575,status=no,resizable=yes'));keyit.focus();){kind=logo}
返回本主题
返回页首
