关于项目的一些看法

08-06-13 forest3000
在Jdon逛了这么久了,对领域建模有了一定的认识,感觉很好。可是,旁边的同学做项目时,都是先设计数据库表,然后增删改查,做界面,项目做的也是很快。而当我自己做项目时,自己想建立领域模型,然而发现,直接通过对数据库操作更直接,也更简单。而且一般不用担心效率问题。我学java也有一段时间了,通过banq的帖子,我已经明白,自己写的代码基本上都是面向过程式的开发。身边的同学都对数据库了解很深,使用的很熟练,虽然我认为他们基本不怎么样,我对他们说数据库时代已经结束了,可是没有人会听我的。现在老师给了一个项目,原本打算用DDD建模,自己好好弄一把,可是一上来发现需求不是很复杂,如果先建表,做起来也许更快。自己很彷徨,明明知道领域建模才是正路,可问旁边人,他们都说数据库才是第一位的,什么计算,统计都交给数据库,界面有操作就行了,痛苦中。。。

请大家给一些建议,谢谢。。。

freebox
2008-06-13 22:36
我认为觉得简单是因为业务太简单了,业务就是CRUD,但是真实业务却不仅仅是CRUD这么简单。这时候是用一个几百行的平面SQL表达得清楚还是几个对象交互表达得明白呢?一旦适应OO了,无论多简单的业务都会首先想到对象而不是db。

java应用程序的效率在于(分布)对象缓存,否则就只有加大db机的硬件配置以适应更高的要求。那一点SQL和对象的效率差异根本不值一提,遗憾的是有时候管理人员不这么看,有时候不得不弄一个dao来使用他们的查询SQL并自己把结果封装成对象。

forest3000
2008-06-14 00:06
多谢freebox的回复,我似乎明白一些东西了,我会努力的,争取使自己能够有OO的思想。。

xmuzyu
2008-06-14 02:03
呵呵,中国这个现象还很严重啊。

banq
2008-06-14 09:26
>原本打算用DDD建模,自己好好弄一把,可是一上来发现需求不是很复杂,如果先建表,做起来也许更快

需求就不是很复杂,用DDD更快,脑子都不用转弯的,为什么你现在觉得DB更快,因为你脑子已经先入为主了,DDD这样正常OO思维你没有了,习惯拐弯思维了,打个比喻:小孩不能学结巴,一旦学了,就一直结巴,正常话都不会说了,这个结巴就是DB,OO就是正常话。结巴的人想说快,总还是结巴,他以为快了,可是我们正常人都会心里发笑。

这里我不是歧视结巴,只是一个比喻,用来说明我们身在庐山中,不识真面貌的可悲状态。

我反对现在传统软件教育的原因,不是要他们全部用OO来教学,而是至少OO和数据库两种并行,让学生有选择,进行一个过渡。

你也不要和你身边DB的程序员争论,他们就是接受这样的教育,他们能找到工作就很满足,他们不是将程序作为事业或兴趣来做。关键是你自己需要恢复正常自然OO思维,这很难,因为让结巴说正常话的可能性有多少呢?

其实Jdon框架的开发视频已经展示了DDD思路下简单开发的快速性,熟练度一样的情况下,可以说几分钟内完全开发一个Model的CRUD功能:

http://www.jdon.com/article/33792.html

[该贴被banq于2008-06-14 10:18修改过]

pub
2008-06-14 11:47
--可是一上来发现需求不是很复杂,如果先建表,做起来也许更快。

程序给别人看也给自己看的

程序做的时候要在乎性能

程序要方便修改 需求变化

如何你的这个程序(项目)以后发展很大了。你写的程序还可以重用吗?

这些你都考虑了吗?

pub
2008-06-14 11:52
带入以上条件考虑 你的答案就呼之欲出...

forest3000
2008-06-14 21:49
多谢大家的回复啊,很是感谢

>他们不是将程序作为事业或兴趣来做

的确是这样的,他们对程序其实没什么兴趣,只是想以后能找个工作,挣点钱就好了(我个人这么认为),不过,还是希望他们能够有好的发展,毕竟都是同学嘛

其实通过在jdon逛的这么长时间,我很认同banq的观点,设计模式,DDD,面向对象思想才是我们应该学习的东西。我看了《Head First设计模式》,《领域驱动设计》,《UML和模式应用》,《企业架构模式》等书(当然,后三本我都只看了一部分,因为一些实在是看不懂)。由于自己动手的机会不是很多,还是很不得软件开发的要领。

最近,老师的项目是关于广告统计的,每天广告的数据投放量是上万条记录。今天我自己也学着,自己建立了一个领域模型,为每个类分配相应的职责,并且画了uml的草图来表示出各个类之间的关联,感觉很不错。但是当需要得到广告总的价钱时(总的价钱=每天每个广告的投放量*每个广告的价格),此时我的类图就需要把这几万条记录load进内存,然后在把相应广告价格信息也load到内存,通过类之间的协作算出总的价钱,这需要很长的时间。而我用多表关联查询和sql函数可以很快的得到结果。当然,我所说的只是应用中的一例,从中,可以很明显的看出数据库的优势。大家说的都很好,但是碰到像现在的这个具体问题时,我就迷茫了,是我的建模太差劲了,还是面向数据库的编程还是有他优势的。。。

>程序做的时候要在乎性能

如果注重性能,对于像上面我所说的大数据量的操作只能全部交给数据库了

xmuzyu
2008-06-15 11:39
呵呵,我们学院现在就开始边OO,边数据库了,但是觉得学OO这东西,要亲自动手做项目,只听老师讲,提高不是很大。

pub
2008-06-15 14:04
--->程序做的时候要在乎性能

---如果注重性能,对于像上面我所说的大数据量的操作只能全部交给数据库了

首先这是一个大的话题。Banq也就这个话题说过太多。搜索一下就可知道。

另外。数据库一块也有细分的:联机事务处理(OLTP)和联机分析处理(OLAP)

如果数据量很大一般会归到olap上去。 对于给人所看到的数据其实并没有那么大。

数据库上做存储过程等无法有效的分布式处理 这些banq都有说了。

不知道你有没有了解Cache这一块?

比如这个

http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=34214&message=23115229#23115229 数据量不可谓不大。这些的系统你用存储过程可以解决吗?

只能说明关于性能你了解还得太少。

另你的眼界着眼于太小的范围让你看到的是眼前一个小圆圈,放开来从大处着眼,就开朗些。。。

---通过类之间的协作算出总的价钱,这需要很长的时间。而我用多表关联查询和sql函数可以很快的得到结果。

---当然,我所说的只是应用中的一例,从中,可以很明显的看出数据库的优势。

DDD中的仓储就是可以和数据库交互的。像聚合函数这些并没有说不能用。只是从仓储中返回的是对象 或对象列表就好。

fw2003
2008-06-16 14:05
>原本打算用DDD建模,自己好好弄一把,可是一上来发现需求不是很复杂,如果先建表,做起来也许更快

很正常嘛

19世纪火车刚发明的时候,只有1节车厢,随着载人增多,车厢会加长,但是过长的车厢在转弯的时候会有困难,因此我们的火车有多节车厢。车厢载人的由少到多代表了一个项目从开始到后期功能上的扩展,转弯意味着需求的变更。而我们现在的火车,通通都是一被造出来就拥有很多节车厢的,相当于我们的设计阶段,而到了某一站后,乘客会按照车票上各自的车厢,相当于架构打好后我们往里面填代码。

banq
2008-06-16 17:32
>此时我的类图就需要把这几万条记录load进内存,然后在把相应广告价格信息也load到内存,通过类之间的协作算出总的价钱,这需要很长的时间。而我用多表关联查询和sql函数可以很快的得到结果。当然,我所说的只是应用中的一例,从中,可以很明显的看出数据库的优势。

因为是两种思维,也就是两个不同世界,或者说两种不同语言,今天你可以举这个具体例子,明天还可以举其他例子,就像你今天指着一个东西说:我知道它的中文是“桌子”,可不知道它的英文是什么?所以,我觉得用“桌子”表示它比较方便。

先回答你这个具体问题,当你用数据库SQL函数查询时,你怎么不知道这几万条记录对数据库服务器不是一个很重的负载呢?如果有几万甚至几十万次个请求这条计算呢?你的数据库吃得消吗?但是你如果使用缓存,将计算结果保存在应用服务器中,那么几万次甚至几十万次的请求就被化解了。

那么就这一次计算相比:是用对象逐个计算还是用SQL函数来查呢?我建议还是用对象逐个计算,将负载拉到对象运行的应用服务器中,这样,这台服务器吃不消时,你可以使用分布式多台服务器来计算,当然,如果某次计算耗费很长时间,你可以抛出一个异步线程专门计算,使用JMS专门来进行计算,多台并行计算。这才是大思路,大架构,这比你成天围着数据库转有扩展性,有发展方向吧?

如果你将这个价格一次计算使用数据库计算,这是躲过了一时,躲不过一世,表面上,应用服务器性能好了,数据库服务器性能也还过得去,那么访问量上升怎么办?倒是成天为了一点性能调校数据库,一台数据库服务器的性能总是有天花板的啊,你能要到多少呢?就象一个人潜力总是有限的,不可能无限的吧?所以,数据库思维总是短视 敷衍了事的思维,就象国有企业员工办事作风一样,这可能也是数据库特别符合中国国情原因所在吧。

你为什么从这里看出数据库的优势,而我没有看到,只看到数据库逆势,所以说:因为你是数据库思维,是结巴表达方式,在你的有色眼中,什么都是红色的。所以,当你觉得数据库有优势时,就要反问自己,真的是这样吗?

虽然看出,你对OO理论很清楚,但是一到动手,又回到数据库思路,没有将两者统一起来,这是中国程序员的通病,说明你们没有经过OO统一教育和培训,OO理论只是业余爱好,没有机会实践,也不知道如何实践,理论和实践严重脱节,这也是传统教育的最大罪过之一。

[该贴被banq于2008-06-16 17:33修改过]

[该贴被banq于2008-06-16 17:38修改过]

freebox
2008-06-16 20:38
几万的记录显然是要分页的。专门开辟一个定时器来计算不能保证实时性,当对这些要求不高时可行。

java的性能绝对不在代码级别,hibernate真正的好处不在ORM,在于缓存。连CPU都在重视缓存,程序当然也要重视了。SQL的确快,但应该比不上内存快,缓存才是性能的重点。

gltbeyond
2008-06-16 22:34
这大概就是我们中国软件的现实吧,我经历的项目不多。

刚进银行做网银时,系统开发的方式也是面向对象的框架下,编写面向过程的代码,java就纯粹来些transaction script 了,我也处处提起,这是与OO背道而驰的,但得到的回复是“OO需要更复杂的对象间管理,一般的程序员根本不具备这个能力;何况我们不是做百年工程,一个网银跑四五年,就很不错了,接下来就得重新构架了”. 虽然不值得赞同,但也能说明现在的现状吧。 现在的设计者90%都是数据表格先行的,设计一个系统,数据库是他们十二分关注的工作,数据库的工作最多就是进行schame,ddl更新...

我参与的两个网银项目,没有见过OO的,顶多对交易数据结构进行一些OO的包装。更别谈MDA,OO职责了。

所以banq大哥布道的路还很长。

不过面向对象的体系风格,在不借助第三方框架的管理下,的确存在很多困难:

1. 在对象间关系的维护的确是件麻烦的事,包括oid的识别。

2. 对象的引用一致性问题,对象发生变化时,是否能够及时更新.

forest3000
2008-06-17 00:19
>先回答你这个具体问题,当你用数据库SQL函数查询时,你怎么不知道这几万条记录对数据库服务器不是一个很重的负载呢?如果有几万甚至几十万次个请求这条计算呢?你的数据库吃得消吗?但是你如果使用缓存,将计算结果保存在应用服务器中,那么几万次甚至几十万次的请求就被化解了。

感觉很有道理。。

>虽然看出,你对OO理论很清楚,但是一到动手,又回到数据库思路,没有将两者统一起来,这是中国程序员的通病,说明你们没有经过OO统一教育和培训,OO理论只是业余爱好,没有机会实践,也不知道如何实践,理论和实践严重脱节,这也是传统教育的最大罪过之一。

我本以为学了设计模式,hibernate等框架,自己应该有OO思想了,通过这次做项目,并且与大家的讨论,我明白了自己原来仍然是OO的菜鸟,仍然需要不断的努力学习。同时感谢banq的布道,至少我现在自己知道自己的不足了。

但是我怎样才能将理论和实践结合起来呢,我看过领域驱动设计,设计模式,可是做起项目来还是会想着数据库,哎。。。。

>这大概就是我们中国软件的现实吧

恩,至少我身边的同学都是这样的,当拿到项目的时候,都是从设计数据库表开始的。我给他们说我们现在用java写的都是面向过程的代码,他们都感到很诧异,java不都是面向对象的吗?通过在Jdon的学习,我至少意识到我以前写都代码都是面向过程的,我会努力,好好学习OO思想

感谢大家的回帖,我会重新考虑一下我们项目的问题,的确,像banq那样所说的,我虽然对OO也是了解的,可是一动手就回到数据库的思路上了,哎,作为一个研二的学生,真是很悲哀。。。我从自己的身上就能看到传统教育的悲哀。。

也许我现在需要对大脑进行好好洗礼,一切从OO开始。。。

猜你喜欢
2Go 1 2 下一页