|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-30
愚蠢的地球人，你们统统都错了
在我们赛伯坦星球，架构师写框架都遵循这些原则： 能省就省，能少就少，能不写就不写。 没办法，我们的程序都是几万万亿行，所以必须要简化。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
mercyblitz 写道 lpn520 写道 mercyblitz 写道 lpn520 写道 lcllcl987 写道 lpn520 写道 t42dw 写道 lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？
当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。 当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂 控制，业务，数据操作分开还是很有道理的 分开当然要分开，Model-View-Controllor三层<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>，再加上DAO一层，总共四层 Model 就是 Action View 就是 JSP Controllor struts2已经实现了，不需要你实现 DAO ibatis已经实现了，你要做的就是在sqlmap.xml里写SQL就行了 你觉得这四层不够应变你所说的业务逻辑变更吗？ 我想问，你业务逻辑变更了，难道真能可以只修改一层，其它层都不用修改吗？ 不要service吗？你的业务逻辑在哪写？你的事务控制在哪控制？在action里面控制吗？卖糕的！ 关于事务问题，请看回贴 12页 的 第9楼 需不需要写Service这一层和事务没有一点关系。 关键一点，如果契约一致的话，这样分开不是什么过度设计问题。 现在把业务放在Service的价值远不如把业务写在Action里，struts2的理念，其实Action就是一个Model。如今是异步处理的时代，Action里的每个业务，不仅可以代码重用，还可以面向HTTP请求的重用，也可以把它独立成一个单独的业务处理。 不要把话题扯开，异步与否和你的需求有关。 现在讨论的是代码组织结构性的问题。 在我Review的项目中，也有你这么思考的。不过还是我以前那句话，如果是简单的场景，没有必要引用复杂组织结构。 但是，你想过这个问题，第一，你对项目角色？我认真开了每一页的内容，在我看来，你并不是能拍板的人，否者你不会在这里说，直接修改了。牵扯出两种可能， 第一种可能，制定软件架构的人，很没有经验，或者过于教条主义。我不了解实际情况，但个人觉得教条可能性比较大，至于经验的尚浅话，那倒是不太可能。因为架构师不是一个人，而是一个团队，难道整个团队都比较二？ 第二种可能，你对架构理解不够，总认为自己是对的，是否对项目全局把握。如果说你那块的东西，是简单的CRUD的话，那么价值不在于是否过度的形式，而是在于你是否认同这种开发模式或者开发规范，如果游戏规则不适应，那是你的角度问题。还有，和其他人是否和你有相同的感受？ 如果有的话，那么属于第一种可能，如果没有，想想自己的原因。 我就提一个很简单的问题吧，如果两个页面处理的是同一种业务逻辑，那你会怎么做，是不是要在action中重复写两个相同的业务逻辑的方法，只把最后返回的URL定为不同？如果你再把这两个相同的业务逻辑抽象出一个公共方法的话，你觉得是分层清晰还是公共方法清晰？在我做过的项目中，这种可复用的业务逻辑占20%~30%，即使你现在没碰到，也不代表以后不会碰到这种情况，难道等真碰到了这种情况再全部重构分层？所以我觉得业务层是绝对必要的。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
t42dw 写道 mercyblitz 写道 xhdwell 写道 southgate 写道 张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 “普通业务写在action里头有什么不好，清晰 简单” 你的清晰简单指的是你自己看吧。你让别人来看看你的程序看。软件工程是个团队工程。不是你一个人在战斗，你希望一个人的便利让10个人帮你擦屁股吗？我做过这样的工程，人都崩溃了。 你这么说，那说明你所在的团队连起码的规范都没有。这样都不行的话，谈什么解耦，谈什么面向接口编程。 我想估计很多人都是从书上听说解耦，至于什么是解耦自己也不太清楚。 说心里话要我解决解耦我还真的说不出来，但是又好像有一点懂!呵呵可能境界没到了 单从概念上很难理解，简单地说，耦合是重复(比如复制粘贴带来的重复，单元或模块之间职责重叠)或组织结构的臃肿。难以甚至无法重复利用以后的单元或模块，组建或模块之间难以或无法通讯。比如，把所有业务写到了JSP。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
xhdwell 写道 mercyblitz 写道 lpn520 写道 mercyblitz 写道 lpn520 写道 lcllcl987 写道 lpn520 写道 t42dw 写道 lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？
当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。 当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂 控制，业务，数据操作分开还是很有道理的 分开当然要分开，Model-View-Controllor三层<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>，再加上DAO一层，总共四层 Model 就是 Action View 就是 JSP Controllor struts2已经实现了，不需要你实现 DAO ibatis已经实现了，你要做的就是在sqlmap.xml里写SQL就行了 你觉得这四层不够应变你所说的业务逻辑变更吗？ 我想问，你业务逻辑变更了，难道真能可以只修改一层，其它层都不用修改吗？ 不要service吗？你的业务逻辑在哪写？你的事务控制在哪控制？在action里面控制吗？卖糕的！ 关于事务问题，请看回贴 12页 的 第9楼 需不需要写Service这一层和事务没有一点关系。 关键一点，如果契约一致的话，这样分开不是什么过度设计问题。 现在把业务放在Service的价值远不如把业务写在Action里，struts2的理念，其实Action就是一个Model。如今是异步处理的时代，Action里的每个业务，不仅可以代码重用，还可以面向HTTP请求的重用，也可以把它独立成一个单独的业务处理。 不要把话题扯开，异步与否和你的需求有关。 现在讨论的是代码组织结构性的问题。 在我Review的项目中，也有你这么思考的。不过还是我以前那句话，如果是简单的场景，没有必要引用复杂组织结构。 但是，你想过这个问题，第一，你对项目角色？我认真开了每一页的内容，在我看来，你并不是能拍板的人，否者你不会在这里说，直接修改了。牵扯出两种可能， 第一种可能，制定软件架构的人，很没有经验，或者过于教条主义。我不了解实际情况，但个人觉得教条可能性比较大，至于经验的尚浅话，那倒是不太可能。因为架构师不是一个人，而是一个团队，难道整个团队都比较二？ 第二种可能，你对架构理解不够，总认为自己是对的，是否对项目全局把握。如果说你那块的东西，是简单的CRUD的话，那么价值不在于是否过度的形式，而是在于你是否认同这种开发模式或者开发规范，如果游戏规则不适应，那是你的角度问题。还有，和其他人是否和你有相同的感受？ 如果有的话，那么属于第一种可能，如果没有，想想自己的原因。 我就提一个很简单的问题吧，如果两个页面处理的是同一种业务逻辑，那你会怎么做，是不是要在action中重复写两个相同的业务逻辑的方法，只把最后返回的URL定为不同？如果你再把这两个相同的业务逻辑抽象出一个公共方法的话，你觉得是分层清晰还是公共方法清晰？在我做过的项目中，这种可复用的业务逻辑占20%~30%，即使你现在没碰到，也不代表以后不会碰到这种情况，难道等真碰到了这种情况再全部重构分层？所以我觉得业务层是绝对必要的。 看了很久，原来你是赞同我的观点，呵呵。 没有错，分层是一种代码组织策略，复用是OOP的核心。所谓的分层，很大程度上就是抽象过程，提出公用的，尽量重复使用。让组建之间职责清晰，关系明确。减少不必要的重复劳动。但是不应该过于形式化。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
深有感触，曾经在一个项目中想把DAO去掉，结果遭到所有人的一致反对。。。
java里面分层设计的思想太根深蒂固了，我觉得J2EE未来还是会朝着简化分层，减少代码量，提高开发效率的方向发展 |
| 返回顶楼 | |
|
发表时间：2010-09-30
应该没有架构的设计吧，这不是架构设计，只是把自己的业务加到别人设计的架构上去了吧，小项目有没有必要分这么多层，我觉得可以仔细权衡一下，如何做更适合当前的项目，只要耦合性低，如果以后项目真需要多加层，那也是比较方便的事情。
|
| 返回顶楼 | |
|
发表时间：2010-09-30
septem 写道 深有感触，曾经在一个项目中想把DAO去掉，结果遭到所有人的一致反对。。。
java里面分层设计的思想太根深蒂固了，我觉得J2EE未来还是会朝着简化分层，减少代码量，提高开发效率的方向发展 我觉得随着软件的复杂，实现同一个业务实现的代码只会增加。因为在一个大型的软件工程中，关心的不是开发量，而且维护量，二次开发量，软件的伸缩性和可扩展性。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
好长的贴子哦。
有几点楼主要注意： 1.一般我们都不会碰上hello world这么好的项目。 2.很多公司是分层开发的，接口真的很重要。 3.并不是所有的项目只有web console。 4.外包公司经常节约成本，一个team leader带群intern在开发，他们需要的不是别的，是规范，是按步就班，请别让他们知道太多。文件多不是问题，只要清晰就好了。 如果是特定的项目，让这些啰哩吧嗦的东西见鬼去吧。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
ORM时代，小型项目去掉DAO层没什么不好。
简洁既是美，经典的模式未必是最好的。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
三层架构，有什么问题？
|
| 返回顶楼 | |
