|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-30
yunhaifeiwu 写道 楼主，转到blog里吧，你这个贴子对许多人都有用。看到java这个自动投分机制，估计你的贴子要被自动隐藏了。
blog里有，欢迎 http://lpn520.iteye.com/blog/774926 |
| 返回顶楼 | |
|
发表时间：2010-09-30
mercyblitz 写道 xhdwell 写道 southgate 写道 张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 “普通业务写在action里头有什么不好，清晰 简单” 你的清晰简单指的是你自己看吧。你让别人来看看你的程序看。软件工程是个团队工程。不是你一个人在战斗，你希望一个人的便利让10个人帮你擦屁股吗？我做过这样的工程，人都崩溃了。 你这么说，那说明你所在的团队连起码的规范都没有。这样都不行的话，谈什么解耦，谈什么面向接口编程。 我想估计很多人都是从书上听说解耦，至于什么是解耦自己也不太清楚。 说心里话要我解决解耦我还真的说不出来，但是又好像有一点懂!呵呵可能境界没到了 |
| 返回顶楼 | |
|
发表时间：2010-09-30
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请求的重用，也可以把它独立成一个单独的业务处理。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
你们架构师的思想局限于各种框架，死板硬套，LZ看不惯的这种设计就是最标准的SSH SSI设计模板
初步估计LZ思想更注重数据库，好比对于"添加"这个业务，似乎更在乎怎么以最简单的方法在数据库里insert记录 |
| 返回顶楼 | |
|
发表时间：2010-09-30
mercyblitz 写道 xhdwell 写道 southgate 写道 张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 “普通业务写在action里头有什么不好，清晰 简单” 你的清晰简单指的是你自己看吧。你让别人来看看你的程序看。软件工程是个团队工程。不是你一个人在战斗，你希望一个人的便利让10个人帮你擦屁股吗？我做过这样的工程，人都崩溃了。 你这么说，那说明你所在的团队连起码的规范都没有。这样都不行的话，谈什么解耦，谈什么面向接口编程。 我想估计很多人都是从书上听说解耦，至于什么是解耦自己也不太清楚。 你把很多情况想的太理想化了，一个团队的素质不是你一个人决定的。而且一个有代码规范的团队会要求把业务放在action中实现吗？控制和业务放在一起本来就是耦合，我不知道你所说的解耦的概念是什么。我并没说一定要面向接口编程才是解耦，但两个不同层面的业务放在一个层面实现肯定是耦合。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
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的话，那么价值不在于是否过度的形式，而是在于你是否认同这种开发模式或者开发规范，如果游戏规则不适应，那是你的角度问题。还有，和其他人是否和你有相同的感受？ 如果有的话，那么属于第一种可能，如果没有，想想自己的原因。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
为什么我觉得这样的分层设计很正常啊。
就3层(mvc,service,dao)，很经典啊，spring的demo petshop就是这样的啊。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
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请求的重用，也可以把它独立成一个单独的业务处理。 表现层 有自已的数据格式与后台通讯，如果把业务放在action里，当要用另外的表现层如不用extjs时，这时，项目几乎是要全部重写。如果action只负责页面跳转、业务层与表现层间的数据转换，那么扔掉extjs时，有很大部份可以重用。当然多一层，就多代码量，复杂性也增加了，如果整体结构都这样，当然公司决定以后N年都要用extjs，把业务层放在action也没什么滴。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
xhdwell 写道 mercyblitz 写道 xhdwell 写道 southgate 写道 张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 “普通业务写在action里头有什么不好，清晰 简单” 你的清晰简单指的是你自己看吧。你让别人来看看你的程序看。软件工程是个团队工程。不是你一个人在战斗，你希望一个人的便利让10个人帮你擦屁股吗？我做过这样的工程，人都崩溃了。 你这么说，那说明你所在的团队连起码的规范都没有。这样都不行的话，谈什么解耦，谈什么面向接口编程。 我想估计很多人都是从书上听说解耦，至于什么是解耦自己也不太清楚。 你把很多情况想的太理想化了，一个团队的素质不是你一个人决定的。而且一个有代码规范的团队会要求把业务放在action中实现吗？控制和业务放在一起本来就是耦合，我不知道你所说的解耦的概念是什么。我并没说一定要面向接口编程才是解耦，但两个不同层面的业务放在一个层面实现肯定是耦合。 这个“解耦”的问题，不是针对你的。 没有理想化的问题，没有游戏规则的话，怎么会有相同的方向，这就是为什么要用框架的原因（我用Servlet比用Struts快很多，而且更加数量）。人人都是各有各意见，难以共事。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
最后修改：2010-09-30
xhdwell 写道 lgc653 写道 喜欢简单直接的约定和结构，讨厌所谓的设计模式和过多配置文件。再大的项目也是由小项目组成的，做好够用的契约和分层一样很好维护，也更容易理解。
设计模式本来就是让程序的层次逻辑更简单明了，这并不冲突。但别一拿到什么问题都往工厂模式，策略模式上去套。在用设计模式之前先要想清楚为什么要用，能解决什么问题。 我只是不喜欢把一些模式和框架当做圣经来膜拜的现状（当然我个人也不认为模式一定能让程序的层次逻辑更简单明了），认为引入了ORM就能很好的做数据库的迁移，认为引入一些AOP和模式就能让代码轻松修改维护，其实这就是盲信。 而且对某些大项目也是谈起来充满信服之情，其实大项目不可能是一个整体，它肯定是一系列相互协作的小项目的合体，不可能是一个仅仅靠代码分层来耦合的巨无霸。 |
| 返回顶楼 | |
