|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-30
看了一半。
好像是我在je里见过分页最多的帖子了 |
| 返回顶楼 | |
|
发表时间：2010-09-30
楼主，转到blog里吧，你这个贴子对许多人都有用。看到java这个自动投分机制，估计你的贴子要被自动隐藏了。
|
| 返回顶楼 | |
|
发表时间：2010-09-30
lpn520 写道 t42dw 写道 lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？
当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。 当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂 控制，业务，数据操作分开还是很有道理的 分开当然要分开，Model-View-Controllor三层，再加上DAO一层，总共四层 Model 就是 Action View 就是 JSP Controllor struts2已经实现了，不需要你实现 DAO ibatis已经实现了，你要做的就是在sqlmap.xml里写SQL就行了 你觉得这四层不够应变你所说的业务逻辑变更吗？ 我想问，你业务逻辑变更了，难道真能可以只修改一层，其它层都不用修改吗？ EXTjs我没用过无法说什么 struts2我自己学过一点我记得其中的方法也需要返回forward这个是否是控制的体现？ 就像之前有一位兄弟说的一样action还需要做数据的处理工作比如验证、组装数据如果将这些都写在一起可读性是否会很差？ 还有一点struts2的action应该不能满足你的需要你可能需要创建一个BaseAction对公共的事件进行处理（异常处理，URL加解密等等）在如此多的复杂性问题面前我觉得创建专门用与控制的action是有必要的，当然我的struts2肯定没有LZ好如有不对还请指教 这个DAO的话一些共用的操作是可以写在一个类中，但是这不能解决所有的问题你肯定还有一些个性化的操作就我自己而言碰到的问题起码有50%是公共操作不能解决的(这里指的是复杂度高的模块)，我认为DAO类还是需要有的公共的方法可以用继承去得到 |
| 返回顶楼 | |
|
发表时间：2010-09-30
southgate 写道 张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 “普通业务写在action里头有什么不好，清晰 简单” 你的清晰简单指的是你自己看吧。你让别人来看看你的程序看。软件工程是个团队工程。不是你一个人在战斗，你希望一个人的便利让10个人帮你擦屁股吗？我做过这样的工程，人都崩溃了。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
嗯 …… 这种东西到处都是，更要命的是一旦业务变动，每层都要改一遍，老费劲了。
有人就是以为写得越多越“灵活”，把复制粘贴当成“重用”，观念以资历增长而根深蒂固化，没办法的。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
lpn520 写道 幽梦新影 写道 分层的结果是简单问题复杂化，复杂问题简单化，写个Hello world你也不用分几层吧
分层是规范，代码要统一，必须这么写，方便以后维护和扩展（架构师原话） 我统一你们架构师说的话。一个系统的业务决不是helloworld这么简单的。规范必须要统一，即使你觉得你现在这个业务不需要分这么多层写也的不得不遵守这个规范。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
现在看 《人机界面设计》 很有感触
有两种设计方式， 1种是 以技术为本， 1种是 以人为本 以技术为本 是工业社会的背景下，以提供机器功能效率的为目标的，只是在技术无法处理的点上才提供部分操作给人，完全忽略了人与机器的特性差异，人只作为机器的部件而存在。这种情况必定导致 用户的不适应，思维负荷加大等情况，不论技术多牛B，只要按着这种设计方式的东西也是一种思维落后的的设计。 这个说法放到我们程序员身上也同样适用。 我们也是用户，而提供服务的就是编程语言，程序架构，软硬件环境。 如果语言难用，环境恶劣，程序架构复杂恶心，我想不论技术，设备多nb,也没什么人会用得舒服的吧。 正如这位兄弟的情况一样， 我觉得架构师设计这个架构也许是考虑了很多因素，也考虑各种技术，目的都是要提供分层清晰，高配置度，低耦合高内聚。 但设计思路完全以技术为本，忽略了人的特性，只是在脑海中建立起的程序生产线上安放各个插槽给程序员实现， 唯独没有考虑到程序员使用的难易程度，简单功能的实现捷径，学习带来的成本，思维负荷，导致这只能是个落后的，人机界面相当不友好的设计。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
xhdwell 写道 southgate 写道 张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 “普通业务写在action里头有什么不好，清晰 简单” 你的清晰简单指的是你自己看吧。你让别人来看看你的程序看。软件工程是个团队工程。不是你一个人在战斗，你希望一个人的便利让10个人帮你擦屁股吗？我做过这样的工程，人都崩溃了。 你这么说，那说明你所在的团队连起码的规范都没有。这样都不行的话，谈什么解耦，谈什么面向接口编程。 我想估计很多人都是从书上听说解耦，至于什么是解耦自己也不太清楚。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
lcllcl987 写道 lpn520 写道 t42dw 写道 lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？
当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。 当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂 控制，业务，数据操作分开还是很有道理的 分开当然要分开，Model-View-Controllor三层，再加上DAO一层，总共四层 Model 就是 Action View 就是 JSP Controllor struts2已经实现了，不需要你实现 DAO ibatis已经实现了，你要做的就是在sqlmap.xml里写SQL就行了 你觉得这四层不够应变你所说的业务逻辑变更吗？ 我想问，你业务逻辑变更了，难道真能可以只修改一层，其它层都不用修改吗？ 不要service吗？你的业务逻辑在哪写？你的事务控制在哪控制？在action里面控制吗？卖糕的！ 关于事务问题，请看回贴 12页 的 第9楼 |
| 返回顶楼 | |
|
发表时间：2010-09-30
lpn520 写道 lcllcl987 写道 lpn520 写道 t42dw 写道 lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？
当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。 当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂 控制，业务，数据操作分开还是很有道理的 分开当然要分开，Model-View-Controllor三层，再加上DAO一层，总共四层 Model 就是 Action View 就是 JSP Controllor struts2已经实现了，不需要你实现 DAO ibatis已经实现了，你要做的就是在sqlmap.xml里写SQL就行了 你觉得这四层不够应变你所说的业务逻辑变更吗？ 我想问，你业务逻辑变更了，难道真能可以只修改一层，其它层都不用修改吗？ 不要service吗？你的业务逻辑在哪写？你的事务控制在哪控制？在action里面控制吗？卖糕的！ 关于事务问题，请看回贴 12页 的 第9楼 需不需要写Service这一层和事务没有一点关系。 关键一点，如果契约一致的话，这样分开不是什么过度设计问题。 |
| 返回顶楼 | |
