|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-30
楼主这种设计在小项目中可以行得通,大项目中,重用性很低,耦合度很高
|
| 返回顶楼 | |
|
发表时间：2010-09-30
xiaoming_320 写道 IcedCoffee 写道 lpn520 写道 wangking717 写道 真想看看那个HELLOWORD分8个的代码，让我见识一下。
让你见识一下传说中的8个文件： 前端 helloWord.jsp //页面文件，不用说了 helloWord.js //javascript文件 Struts的Action，就叫动作层吧 HelloWordAction.java //Action类文件，客户端请求到这个类上 业务层 HelloWordService.java //业务接口， 还用了一套传说中的“面向接口编程” HelloWordServiceImp.java //业务实现类，实现上面定义的接口 DAO层 HelloWordDao.java //数据操作类，关于HelloWord业务的数据操作都在这里 HelloWord.java //HelloWord表的ORM的对象 HelloWord.xml //HelloWord表操作的SQL语句，ibatis的sqlmap 这个真的很正常... 恩 我也觉的很正常。 这个太正常不过了! |
| 返回顶楼 | |
|
发表时间：2010-09-30
楼主可能还是从以前在JSP中直接写所有逻辑刚转到MVC三层结构，所以大惊小怪的！
|
| 返回顶楼 | |
|
发表时间：2010-09-30
t42dw 写道 mercyblitz 写道 xhdwell 写道 southgate 写道 张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 “普通业务写在action里头有什么不好，清晰 简单” 你的清晰简单指的是你自己看吧。你让别人来看看你的程序看。软件工程是个团队工程。不是你一个人在战斗，你希望一个人的便利让10个人帮你擦屁股吗？我做过这样的工程，人都崩溃了。 你这么说，那说明你所在的团队连起码的规范都没有。这样都不行的话，谈什么解耦，谈什么面向接口编程。 我想估计很多人都是从书上听说解耦，至于什么是解耦自己也不太清楚。 说心里话要我解决解耦我还真的说不出来，但是又好像有一点懂!呵呵可能境界没到了 很明显，什么是解耦都不知道，怎么样的设计才是低耦合，高内聚的，都分不清，没资格评价人家的设计 |
| 返回顶楼 | |
|
发表时间：2010-09-30
最后修改：2010-09-30
matt.u 写道 zdmcjm 写道 别争了，都来用grails吧，正常人用过grails后，都不会再想用java开发所谓的企业级应用了。
的确是这样，grails有很多我所希望的东西，不过就是有点缺陷，修改了代码后需要等待很久才能重新热部署完成。同时期待groovy++。 你们项目修改后，需要重新热部署很久吗？大概多久，我的一般２－３秒。您是不是没设jvm参数？你们用grails做项目，分不分出一个service层？ |
| 返回顶楼 | |
|
发表时间：2010-09-30
存在即合理，没标准的东西不需要这么多争论
企业的不同阶段需要采用不同的开发方式 统一一种方式才奇怪了 还是因地制宜是核心 |
| 返回顶楼 | |
|
发表时间：2010-09-30
xhdwell 写道 keshin 写道 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%，即使你现在没碰到，也不代表以后不会碰到这种情况，难道等真碰到了这种情况再全部重构分层？所以我觉得业务层是绝对必要的。 额，首先，我赞同mercyblitz的意见，要么挑战规则，要么遵守规则，发牢骚个人认为并无多少实质意义 另外，你说的这种情况，我觉得action mapping 定义两个指向同一个action类即可 那返回页面呢？你难道还要做个if-else判断吗？而且两个action mapping指向同一个action你觉得合理吗？别人看的懂吗？ action 只需返回success 或者 error之类的result <action name="view" class="actionclass"> <result name="success">/view.jsp</result> </action> <action name="admin/view" class="actionclass"> <result name="success">/admin/view.jsp</result> </action> 这样就不需要在action类中显示的执行if-else，当然，你要说这个if else 在配置层也行。 另外，多个action-mapping指向一个action我并不认为有什么不可。 service层是必须的，我这种做法，相当于把action类视为有状态的service层。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
分层是有意义的，每层职责不同。比如说sql只出现在dao层中。如果有了通用的持久化工具（hibernate），大部分dao对象是可以省略的，有特殊持久需求的话再建dao。
我认为mvc框架的控制层都是可以当应用接口层用的。 如果只做跳转和调用服务我何必用mvc框架？ jsp和servlet来做不就可以了，封装请求参数到对象属性不过是一个util方法而已。 至于那些只有一个XXXXServiceImpl的service接口就没存在的必要了 |
| 返回顶楼 | |
|
发表时间：2010-09-30
keshin 写道 xhdwell 写道 keshin 写道 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%，即使你现在没碰到，也不代表以后不会碰到这种情况，难道等真碰到了这种情况再全部重构分层？所以我觉得业务层是绝对必要的。 额，首先，我赞同mercyblitz的意见，要么挑战规则，要么遵守规则，发牢骚个人认为并无多少实质意义 另外，你说的这种情况，我觉得action mapping 定义两个指向同一个action类即可 那返回页面呢？你难道还要做个if-else判断吗？而且两个action mapping指向同一个action你觉得合理吗？别人看的懂吗？ action 只需返回success 或者 error之类的result <action name="view" class="actionclass"> <result name="success">/view.jsp</result> </action> <action name="admin/view" class="actionclass"> <result name="success">/admin/view.jsp</result> </action> 这样就不需要在action类中显示的执行if-else，当然，你要说这个if else 在配置层也行。 另外，多个action-mapping指向一个action我并不认为有什么不可。 service层是必须的，我这种做法，相当于把action类视为有状态的service层。 如果service层有供其他方式调用的需求，比如，webservice，比如hession等等，那么一个无状态的独立的service层自然是必须的。 但如果没有这样的需求，那么把controller层和service层合并使之成为有状态的service层，我认为并无不可。 况且，如果使用的是struct2，假如设计得当，那么所谓的action类，也可以无缝变成service层 |
| 返回顶楼 | |
|
发表时间：2010-09-30
lianglaiyang 写道 t42dw 写道 mercyblitz 写道 xhdwell 写道 southgate 写道 张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 “普通业务写在action里头有什么不好，清晰 简单” 你的清晰简单指的是你自己看吧。你让别人来看看你的程序看。软件工程是个团队工程。不是你一个人在战斗，你希望一个人的便利让10个人帮你擦屁股吗？我做过这样的工程，人都崩溃了。 你这么说，那说明你所在的团队连起码的规范都没有。这样都不行的话，谈什么解耦，谈什么面向接口编程。 我想估计很多人都是从书上听说解耦，至于什么是解耦自己也不太清楚。 说心里话要我解决解耦我还真的说不出来，但是又好像有一点懂!呵呵可能境界没到了 很明显，什么是解耦都不知道，怎么样的设计才是低耦合，高内聚的，都分不清，没资格评价人家的设计 兄弟你要谈定，我没有去评价只是提出自己的看法，楼主开个贴子不就是为了大家都提出自己的看法一起讨论吗？ 如想愤青去约鱼岛吧那里需要你 |
| 返回顶楼 | |
