|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-30
架构本身没有好坏之分， 在成本和进度的范围内完成项目就可以。
如果是做产品或运营的项目， 分层的架构是必须的， 维护、扩展要考虑进去。 如果是做普通项目， 主要考虑快速开发，可以适当简化架构。 |
| 返回顶楼 | |
|
发表时间：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%，即使你现在没碰到，也不代表以后不会碰到这种情况，难道等真碰到了这种情况再全部重构分层？所以我觉得业务层是绝对必要的。 额，首先，我赞同mercyblitz的意见，要么挑战规则，要么遵守规则，发牢骚个人认为并无多少实质意义 另外，你说的这种情况，我觉得action mapping 定义两个指向同一个action类即可 |
| 返回顶楼 | |
|
发表时间：2010-09-30
既然都用ext了，还要jsp干吗，页面全都是html。
|
| 返回顶楼 | |
|
发表时间：2010-09-30
lpn520 写道 给你看看我之前做的解决方案，同样“添加删除修改查询”，同样是Struts2+Spring+iBATIS+ExtJs ...... 感觉LS应该先学学啥叫耦合...然后再去看看这个架构师的设计,而且 个人认为 除了那个js可以去掉之外,其他的都应该保留... |
| 返回顶楼 | |
|
发表时间：2010-09-30
现在框架什么的都不重要，只要代码清晰，别人看的懂，易维护就行，要多写注释。最好项目一开始就上持续集成，findbug pmd checkstyle之类的。。。。。。像华为那样BT的检测更好。。。虽然我有点偏激。。。
|
| 返回顶楼 | |
|
发表时间：2010-09-30
最后修改：2010-09-30
设计太多的分层，以及偶和性太高，添加或修改一个模块太困难了，而且还不知道会不会影响到其它模块。毫不夸张地说，写一个Hello world，创建的代码文件个数必须达到8个！！！！
过度分层已经成为过度设计的一个典型。项目经理说，这是另一个项目的架构直接搬过来用的，我们做一下架构上的优化。
记得OSI7层模型就有过度设计嫌疑，可以去看一下现在的教材，都没有用OSI作为例子，尤其没有专门讨论会话层。
如何防止过度设计，最好办法就是使用敏捷编程，他的思路就是刚刚好就行，如果有问题，再重构。另外我自己目前的实践方法就是多编程，少设计，好像也能避免。因为当你的任务主要是写代码的时候，你绝不会去写8个类来完成一个helloworld。
其实，我所说的就是开发原型，也是《敏捷开发方法》里提到过的方法。
这是我们架构师设计的传说中的8个文件：
前端 helloWorld.jsp //页面文件，不用说了，用了EXT，里面其实没代码 helloWorld.js //javascript文件 struts2的Action，大众认为是控制层 HelloWorldAction.java //Action类文件，客户端请求到这个类上 业务层 HelloWorldService.java //业务接口， 还用了一套传说中的“面向接口编程” HelloWorldServiceImp.java //业务实现类，实现上面定义的接口 DAO层 HelloWorldDao.java //数据操作类，关于HelloWorld业务的数据操作都在这里 HelloWorld.java //HelloWorld表的ORM的对象 HelloWorld.xml //HelloWorld表操作的SQL语句，ibatis的sqlmap 同样“添加删除修改查询”，同样是Struts2+Spring+iBATIS+ExtJs， 下面是我常用的解决方案
前端 helloWorld.jsp //用过Ext的都知道，页面是不需要写HTML代码的，所以helloWorld.js直接可以省掉，直接把js写在jsp文件里，还有用EXT直接使用原生态的，封装一层真的很恶心 控制层 //struts2框架内部实现了控制层，所以不需要自己添加实现代码 业务层 HelloWorldAction.java //struts2的Action，本身就是动作的意思，为什么它不叫Controllor呢，因为控制类已经在框架内部封装好了，你实现了Action接口的类，其实就是Model，我想大家得去重新认识一下struts2。所谓动作类，其实就是在类里写业务，再加上struts2每个请求可以对应到Action的一个个方法上，它不仅可以面向代码的重用，还能面向HTTP请求的重用，所以它完成可以代替掉HelloWorldServer.java和HelloWorldServerImp.java。 //很多人提到事务问题，请看回贴 12页 的 第9楼 DAO层 //再讨论一下DAO层，我们用了ibatis框架，他本身就是个DAO层的实现，把SQL封装在XML中，你每个SQL操作调起来就像调用DAO里的每个方法一样，所以HelloWordDao.java就可以去掉了，像HelloWordDao.java里的每个方法就一条代码，我觉得没什么意思 //所以只要下面两个自动生成的文件就可以了 HelloWord.java //HelloWord表的ORM的对象 HelloWord.xml //HelloWord表操作的SQL语句，ibatis的sqlmap 1.我没觉得架构师设计的传说中的8个文件是是过度设计,因为实在太正常不过了。耦合性太高是你们内部设计以及业务代码相关设计(如互相乱调用，没有统一的接口之类)的问题，和这个分层有什么关系？分层本来就是为了解决耦合问题的。
2.如果说像我们现在的分布式的flex+puremvc(facade.as,mediator.as,Command.as,BizVo.as,proxy.as)+blazeds+BizFacade(Facade.java,BizDto.java)+BizService(interface.java,impl.java)+BizDao(hbm+entity java)+BaseDao 项目，新建一个模块绝对远远超过你说的8个文件，是不是该被你叼死？
3.你说的一个hello world就需要8个文件，其实就相当于新建一个模块了，我没觉得8个文件很多。加上配置文件更加多。
4.我不同意你的把Service层去掉的观点，复杂的系统里，Service层里面还有很多事情要做,不光光是事务的问题，比如和前面的flexFacade打交道，和其它系统的WebService同步,jms队列操作，工作流等等。你直接放到struts的action里去做，是我很不赞成的。
5.一个架构的设计，不能说你开发越快就越好，很多时候还要考虑良好用户体验、架构清晰、易理解、可维护性、分布高可用性等问题。开发时间长，那就安排开发时间就好了。从来不会说你开发说不大好，就换架构的了。一般都是前期定下的。但从实际的经验来说，这样的分层，并不需要你花更多的时间。一方面可以用代码工具生成，然后小修改。再不行吧，你复制粘贴也花不了多少时间。
6.在运用一些技术的前题下，一些层是可以去掉的。如Dao层（BizDao.java,BizDaoImpl.java）。如用了泛型及hibernatetemplate的BaseDao后，BaseDao可以做所有的orm的操作。去掉不去掉Dao层本来就是仁者见仁，智者见智的问题，看个人喜好了。所以你的批判没有道理。
|
| 返回顶楼 | |
|
发表时间：2010-09-30
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你觉得合理吗？别人看的懂吗？ |
| 返回顶楼 | |
|
发表时间：2010-09-30
godfish 写道 架构本身没有好坏之分， 在成本和进度的范围内完成项目就可以。
如果是做产品或运营的项目， 分层的架构是必须的， 维护、扩展要考虑进去。 如果是做普通项目， 主要考虑快速开发，可以适当简化架构。 我认为任何项目都是有维护的，毕竟软件的生命周期中运行是占最大部分时间，只要有运行就会有维护。一个开发人员必须要考虑到今后的维护工作，即使今后不是你在维护。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
绝对的过度设计,我就把dao砍掉了,一般项目,根本不需要那么复杂!!!
|
| 返回顶楼 | |
|
发表时间：2010-09-30
唉，做软件讲究的是艺术，像这样下去，还有什么意思？你要是觉得设计师设计不妥就应当面跟他说啊。
|
| 返回顶楼 | |
