关于项目的一些看法

1 2 ► 共有 21 回复(2页) 阅读243次

forest3000

发表文章: 26
注册时间: 2007年04月24日

悄悄话

个人博客

当前离线

关于项目的一些看法	2008年06月13日 21:28
技巧心得 DDD领域驱动设计数据库 oo面向对象

顶一下

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

freebox

发表文章: 369
注册时间: 2008年03月01日

悄悄话

个人博客

当前离线

re:关于项目的一些看法

2008年06月13日 22:36

顶一下

我认为觉得简单是因为业务太简单了，业务就是CRUD，但是真实业务却不仅仅是CRUD这么简单。这时候是用一个几百行的平面SQL表达得清楚还是几个对象交互表达得明白呢？一旦适应OO了，无论多简单的业务都会首先想到对象而不是db。
java应用程序的效率在于（分布）对象缓存，否则就只有加大db机的硬件配置以适应更高的要求。那一点SQL和对象的效率差异根本不值一提，遗憾的是有时候管理人员不这么看，有时候不得不弄一个dao来使用他们的查询SQL并自己把结果封装成对象。

forest3000

发表文章: 26
注册时间: 2007年04月24日

悄悄话

个人博客

当前离线

re:关于项目的一些看法

2008年06月14日 00:06

顶一下

多谢freebox的回复，我似乎明白一些东西了，我会努力的，争取使自己能够有OO的思想。。

xmuzyu

发表文章: 425
注册时间: 2007年03月26日

悄悄话

个人博客

当前离线

16人关注

re:关于项目的一些看法

2008年06月14日 02:03

顶一下

呵呵，中国这个现象还很严重啊。

banq

发表文章: 11282
注册时间: 2002年08月03日

悄悄话

个人博客

当前离线

70人关注

回复:关于项目的一些看法

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

发表文章: 118
注册时间: 2008年04月13日

悄悄话

个人博客

当前离线

re:关于项目的一些看法

2008年06月14日 11:47

顶一下

--可是一上来发现需求不是很复杂，如果先建表，做起来也许更快。
程序给别人看也给自己看的
程序做的时候要在乎性能
程序要方便修改需求变化
如何你的这个程序（项目）以后发展很大了。你写的程序还可以重用吗？
这些你都考虑了吗？

pub

发表文章: 118
注册时间: 2008年04月13日

悄悄话

个人博客

当前离线

回复:re:关于项目的一些看法

2008年06月14日 11:52

顶一下

带入以上条件考虑你的答案就呼之欲出...

forest3000

发表文章: 26
注册时间: 2007年04月24日

悄悄话

个人博客

当前离线

re:关于项目的一些看法

2008年06月14日 21:49

顶一下

多谢大家的回复啊，很是感谢

>他们不是将程序作为事业或兴趣来做
的确是这样的，他们对程序其实没什么兴趣，只是想以后能找个工作，挣点钱就好了（我个人这么认为），不过，还是希望他们能够有好的发展，毕竟都是同学嘛

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

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

>程序做的时候要在乎性能
如果注重性能，对于像上面我所说的大数据量的操作只能全部交给数据库了

xmuzyu

发表文章: 425
注册时间: 2007年03月26日

悄悄话

个人博客

当前离线

16人关注

回复:回复:关于项目的一些看法

2008年06月15日 11:39

顶一下

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

pub

发表文章: 118
注册时间: 2008年04月13日

悄悄话

个人博客

当前离线

回复:re:关于项目的一些看法

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

发表文章:
注册时间: 2007年05月23日

悄悄话

个人博客

当前离线

re:关于项目的一些看法

2008年06月16日 14:05

顶一下

>原本打算用DDD建模，自己好好弄一把，可是一上来发现需求不是很复杂，如果先建表，做起来也许更快

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

banq

发表文章: 11282
注册时间: 2002年08月03日

悄悄话

个人博客

当前离线

70人关注

回复:re:关于项目的一些看法

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

发表文章: 369
注册时间: 2008年03月01日

悄悄话

个人博客

当前离线

re:关于项目的一些看法

2008年06月16日 20:38

顶一下

几万的记录显然是要分页的。专门开辟一个定时器来计算不能保证实时性，当对这些要求不高时可行。
java的性能绝对不在代码级别，hibernate真正的好处不在ORM，在于缓存。连CPU都在重视缓存，程序当然也要重视了。SQL的确快，但应该比不上内存快，缓存才是性能的重点。

gltbeyond

发表文章:
注册时间: 2007年04月05日

悄悄话

个人博客

当前离线

回复:re:关于项目的一些看法

2008年06月16日 22:34

顶一下

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

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

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

不过面向对象的体系风格，在不借助第三方框架的管理下，的确存在很多困难：
1. 在对象间关系的维护的确是件麻烦的事，包括oid的识别。
2. 对象的引用一致性问题，对象发生变化时，是否能够及时更新.

forest3000

发表文章: 26
注册时间: 2007年04月24日

悄悄话

个人博客

当前离线

re:关于项目的一些看法

2008年06月17日 00:19

顶一下

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

感觉很有道理。。

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

我本以为学了设计模式，hibernate等框架，自己应该有OO思想了，通过这次做项目，并且与大家的讨论，我明白了自己原来仍然是OO的菜鸟，仍然需要不断的努力学习。同时感谢banq的布道，至少我现在自己知道自己的不足了。
但是我怎样才能将理论和实践结合起来呢，我看过领域驱动设计，设计模式，可是做起项目来还是会想着数据库，哎。。。。

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

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

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

技巧心得(17) DDD领域驱动设计(211) 数据库(187) oo面向对象(133)

共有 21 回复(2页) 1 2 ►