CSDN博客

img gojava

O/R Mapping是末,OOAD是本

发表于2005/1/1 15:07:00  740人阅读

ORM工具使用的好不好,首先取决与OO设计是否好. 数据库都是会用的,但OO设计不是都会做的.
如果是事物脚本(Transaction Script)方式,用ORM工具可能只会增加麻烦. 要是自觉得自己OO还不过关,那么
对ORM工具也不宜投入太大精力.

如果DB设计的不好...做ORM也非常费劲..比如我们现在公司的DBA非常喜欢把userid..username..这两个字段分布到每个和user关联的表中...这样他查询这些表时不需要与user表关联再读username...而且这老兄从来不用id字段...都喜欢根据业务逻辑建立联合主键...唔..痛苦异常

目前来看OO技术是很适合业务系统的。如果说OO是本,ORM是末的话,现在不少人可能有点本末倒置。

大家都说用Hibernate先进、用Hibernate代码量少,就要在下个项目上用Hibernate,可能发现除了SQL变成
HQL后,其它也没什么变化,还会觉得有些用SQL能搞定的事情现在用了HQL反到搞不定了。

我觉得这样的问题主要在于OO不行,OO不行又集中 表现在OOAD不行。而OOAD始终没有好的学习途径, 通常的GRASP,名词法这样的工具方法,面对实际的 项目显得力不从心(colorUml好象到是非常实惠)。
而各种教材样例又显得过于玩具。

深有体会...
原来有一个delphi系统,现在用JAVA来做成B/S的。那帮老大死活接受不了hibernate,痛苦一阵后,只好放弃了。

问题集中在以下几个方面:
1.数据库由他们设计,他们不习惯用逻辑ID,喜欢用业务主键。这也还好,可是他们还喜欢用组合的业务主键。开始时,他们尝试使用逻辑ID,但后来终究以不能适应告终。

2.喜欢在一个表中存入关联表中多个字段,而不只是关联主键,说是为了提高查询效率。而我建议到后期进行查询的优化,尽量花小的代价保持数据一致性。

3.在第2个问题中,也有因为业务需要保留历史记录的,所以存放关联表中的多个字段。
例如:在交易表中记录帐户行编号同时记录帐户行外部帐号和内部帐号。本来我想剔除后面两项,只用帐户行编号来关联。但他们说有时帐户行信息改变了,但是查询统计时又希望看到当时交易资金流向的实际帐号。
这个问题不知道怎么解决,我总感觉是需求出了问题,可能是需求上应该进行更细致的分析。

不习惯用OO方式思考,没有对象建模,直接就是数据库设计。例如信用证LC,我觉得应该抽出来作为一个对象,而他们直接就是设计开证信息表,将信用证信息和其他业务信息混在一堆。
想想他们那时用DELPHI开发,大多就是先搞搞需求的分析,然后就是画出功能界面,然后针对界面弄张表,存放界面填写的数据。然后写函数,设置到事件触发。
现在的旧系统还是能用的,但是所有的开发人员都在外面维护或做二次开发。一旦碰到某点需求的改动,动不动就是一帮人在外面弄几个月。

我原来在沿海地区搞开发,现在在内地搞开发,感觉两地的程序员思考的方式完全两样。一阵痛苦的沟通之后,他们认为问题出在hibernate身上,所以要放弃hibernate,改用JDBC。我觉得问题并不在hibernate身上,而是OO的问题。即便用JDBC,我想还是会碰到上面说的问题。现在我已经放弃了,因为势单力薄,你觉得有办法说服他们么?

阅读全文
0 0

相关文章推荐

img
取 消
img