|
锁定老帖子 主题：Spring带来了什么？OOD学而无用
精华帖 (0) :: 良好帖 (9) :: 新手帖 (19) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2013-04-19
最后修改：2013-04-19
gdpglc 写道 suene 写道 Controller --> DomainService --> Repository<Domain> 这样的方式,一样可以 DDD . 你这个和 action service dao 有什么区别？这不还是事务脚本吗？ 好吧,如果你只看设计,就不要去想 WEB 的技术实现了. 去设计你的 Domain 吧. 然后你再来说用什么框架,用什么技术去实现. |
| 返回顶楼 | |
|
发表时间：2013-04-19
suene 写道 gdpglc 写道 suene 写道 Controller --> DomainService --> Repository<Domain> 这样的方式,一样可以 DDD . 你这个和 action service dao 有什么区别？这不还是事务脚本吗？ 好吧,如果你只看设计,就不要去想 WEB 的技术实现了. 去设计你的 Domain 吧. 然后你再来说用什么框架,用什么技术去实现. 把dao改个名就能称为OOD或DDD... 没看懂你要说什么？ |
| 返回顶楼 | |
|
发表时间：2013-04-19
gdpglc 写道 suene 写道 gdpglc 写道 suene 写道 Controller --> DomainService --> Repository<Domain> 这样的方式,一样可以 DDD . 你这个和 action service dao 有什么区别？这不还是事务脚本吗？ 好吧,如果你只看设计,就不要去想 WEB 的技术实现了. 去设计你的 Domain 吧. 然后你再来说用什么框架,用什么技术去实现. 把dao改个名就能称为OOD或DDD... 没看懂你要说什么？ 你引用的那个 08 年那个帖子,就简单的说了 DAO 和 Repository 的区别.只是改个名字么? 看来沟通有困难啊. 设计可以去按照 OOD 去设计, 但实现用不用 Spring ,用不用 Controller --> DomainService --> Repository<Domain>,层次关系,那是另外一个问题. 当然,我说的也未必对,但我能看懂你说的,我只是发表下看法. 我觉得我说的很清楚了,你如果还看不懂.....继续坚持你的观点吧...... |
| 返回顶楼 | |
|
发表时间：2013-04-19
DDD 中,提到的理念. 维护 Domian 的生命周期是使用 Factory Repository.
Repository 和以前的 DAO(Data Access Objects) 是不一样的.( 虽然实质上都是执行sql的东西) 但一个是操作数据库,一个是操作持久化对象. 概念上的东西.你要说就是改了个名字.................. |
| 返回顶楼 | |
|
发表时间：2013-04-19
最后修改：2013-04-19
其实这个贴子我本来就没想讨论spring能不能充血这个问题。否则标题就该叫：spring不能实现充血模型。
我主要针对的spring应用的现状来思考的。 把目光放在技术里是找不到spring和ood的因果关系的。我也没说过因为有了spring所以不能OOD。 我说的是web项目在作技术选择时，spring的过程表达简单易行，是软件架构的首选。这种情况下OOD就是次要的了。 贴子里多数人不是在讨论这个主题。 希望再看到这个贴子的人，能明白我说的意思。 |
| 返回顶楼 | |
|
发表时间：2013-04-19
gdpglc 写道 其实这个贴子我本来就没想讨论spring能不能充血这个问题。否则标题就该叫：spring不能实现充血模型。
我主要针对的spring应用的现状来思考的。 把目光放在技术里是找不到spring和ood的因果关系的。我也没说过因为有了spring所以不能OOD。 我说的是web项目在作技术选择时，spring的过程表达简单易行，是软件架构的首选。这种情况下OOD就是次要的了。 贴子里多数人不是在讨论这个主题。 希望再看到这个贴子的人，能明白我说的意思。 大神,那你这个标题 : Spring带来了什么？OOD学而无用 不是因果关系的意思? 好吧,我想起来了,小学老师教过用 ? 分割的是两句话.呵呵. 你另外开帖吧. |
| 返回顶楼 | |
|
发表时间：2013-04-19
最后修改：2013-04-19
suene 写道 设计可以去按照 OOD 去设计, 但实现用不用 Spring ,用不用 Controller --> DomainService --> Repository<Domain>,层次关系,那是另外一个问题. 这个想法，是很奇怪的。 设计中包括实现框架是必然的，这显然是一个重要的设计内容，除非已形成约定。 设计应该可以简单的翻译成实现。 如果设计做完了，还有许多不确定因素，那完成的部份也可能是不稳定的。 |
| 返回顶楼 | |
|
发表时间：2013-04-19
最后修改：2013-04-20
suene 写道 gdpglc 写道 其实这个贴子我本来就没想讨论spring能不能充血这个问题。否则标题就该叫：spring不能实现充血模型。
我主要针对的spring应用的现状来思考的。 把目光放在技术里是找不到spring和ood的因果关系的。我也没说过因为有了spring所以不能OOD。 我说的是web项目在作技术选择时，spring的过程表达简单易行，是软件架构的首选。这种情况下OOD就是次要的了。 贴子里多数人不是在讨论这个主题。 希望再看到这个贴子的人，能明白我说的意思。 大神,那你这个标题 : Spring带来了什么？OOD学而无用 不是因果关系的意思? 好吧,我想起来了,小学老师教过用 ? 分割的是两句话.呵呵. 你另外开帖吧. 是因果关系，但不是技术范畴内的直接因果。是项目技术选择、风险控制层面的因果。仔细思考一下吧，我显然和你的数学老师说的不是一回事。 只把Dao改成Factory Repository是不能实现OOD的。 比较直观的问题，如何在领域对象中访问数据库？ suene 写道 我觉得LZ最大的分歧在于OOD 的话. 把Domain 的行为写在 Domain 里才算是 OOD.
设计的时候可以看作 Domain 去设计,实现的时候也可以写在 Service 里. 一个 Domain 对应一个 Service. 仅此而已. 你理解我说的意思。但你的想法和结论都是不着边际的。 1.OO的基本思想就是通过有行为的对象构建程序，这没什么可分歧的。 2.你的意思等于是说：OOD的设计最后转换成面向过程的实现（事务脚本）。设计和实现采用两种形式，这不是给自已找麻烦吗？OOA OOD OOP，一个很大的优点是没有语义断层。你的做法是努力的加大语义断层。 你的想法真的很奇怪。把dao改个名，原来怎么实现现在还怎么实现，然后自已就认为是OOD了，有点啊Q的感觉。 在领域对象里放入业务逻缉这是充血的基本含意。如果你认为service类就是领域类，那就没必要讨论了。 |
| 返回顶楼 | |
|
发表时间：2013-04-20
最后修改：2013-04-20
这个贴子里很多的发言其实都是在证明我的结论。
关于OOD的认识，十个人能说出来八个样来。 但是提到spring的常规用法，大家都知道。 在软件必须团队开发的今天，你是项目经理，你会用OOD吗？ |
| 返回顶楼 | |
|
发表时间：2013-04-21
最后修改：2013-04-21
gdpglc 写道 这个贴子里很多的发言其实都是在证明我的结论。
关于OOD的认识，十个人能说出来八个样来。 但是提到spring的常规用法，大家都知道。 在软件必须团队开发的今天，你是项目经理，你会用OOD吗？ 我在作设计时 如果 用流程图能画的清楚的东西 坚决 不会用面向对象, 也就是大家常见的 1Action + 1Service + 1DAO 一个流程图干七八个动作.很easy 这些年来 时序图只有作一个 openid 的模块画过 状态图最近team画手机的复杂界面时才少少使用一下. 架构设计的越好 使用的图越简单 |
| 返回顶楼 | |
