`
lpn520
  • 浏览: 46507 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

“过度设计”之真实例子

阅读更多
  我刚到了一家新公司,公司给我的感觉很不错,不过当开始做第一个项目时便有过度设计的嫌疑,项目不大,基本就实现CURD的功能,用struts2+spring+ibatis+extjs。拿我开发的一个简单的功能来讲,就花了大概一周,如果采用简化的技术,实际上可能只需要一两天。

  设计太多的分层,以及偶和性太高,添加或修改一个模块太困难了,而且还不知道会不会影响到其它模块。按照项目定义的规范做法,写一个Hello world,创建的代码文件个数必须达到8个!!!!

  过度分层已经成为过度设计的一个典型。项目经理说,这是另一个项目的架构直接搬过来用的,我们做一下架构上的优化。

  其实本来就没有什么优化,原来本就是简单的东西,为了显示技术,搞得特复杂。现在所谓的优化,实际上回归质朴而已。

  记得OSI7层模型就有过度设计嫌疑,可以去看一下现在的教材,都没有用OSI作为例子,尤其没有专门讨论会话层。

  如何防止过度设计,最好办法就是使用敏捷编程,他的思路就是刚刚好就行,如果有问题,再重构。另外我自己目前的实践方法就是多编程,少设计,好像也能避免。因为当你的任务主要是写代码的时候,你绝不会去写8个类来完成一个helloworld。

  其实,我所说的就是开发原型,也是《敏捷开发方法》里提到过的方法。


分享到:
评论
270 楼 piao_bo_yi 2011-01-07  
lpn520 写道
downpour 写道
lpn520 写道

通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。
我大概的总结一下:

前端:
helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。

DAO层:
其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。

Service层:
目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。





这种分层开发讨论的帖子,应该出现在05年以前,现在再来讨论,并且讨论了25页,实在是让人觉得是一种悲哀。我把帖子投到新手区,希望楼主更多的思考。

我可以简单回答你的几个困惑。

1. DAO层被证明是可以简化的,至少会一个非常薄的层次。在绝大多数的情况下,DAO层是可以省略的,或者使用一个GenericDao的通用设计即可。Javaeye上已经出现过很多通用DAO的尝试,并且非常成功,楼主可以去查找一下。但是当项目成倍扩张后,DAO作为一个独立的层次就显得比较有必要,因为独立的DAO能够从类和接口声明2个不同的角度诠释一个调用的逻辑含义。

2. Service层和Action层被证明是必须独立分开的2个层次。将2个层次分开的原因很多,其中一个重要原因是Service层将被用于事务的隔离,而Action层是不适合作为事务配置的层次。Action是表示层MVC中的Controller,而Service是业务逻辑层的接口表述,所以这两者的职责是完全不同的。把逻辑全部放到

3. 从你们使用EXTJS的情况看,这个与JSP同名的文件的本意可能是用于渲染页面的。这个是否是过度设计要视项目的情况而言。


看了你的评论,我真的,很怀疑你没有认真看我的帖子,或根本没有理解我的本意。
对于开发分层,我只能说现在的分层太形式化了,我只是想革新现在这种过于形式的编程而已。
至于说帖子应该出现在05年以前,我很遗憾的告诉你,05年我还在读书, 至于现在来讨论有何不可呢?技术本来就是一种更新换代的东西,不是一成不变的。
至于希望我更多的思考, 其实我也想叫你思考:据国外的某机构统计,现在的JAVA的B/S开发生产率远不如PHP,可以说JAVA占尽的优势,可会出现这样的结果,这是为什么呢? 你不觉得这个才是悲哀吗?像你这种这么不给晚辈空间的人,以后你儿子可能也会成为你的悲哀。。。

看了你帮我回答的几个困惑,我非常感谢,1、3 这两点我的总结已经写的很清楚了。
关于Service层和Action层被证明是必须独立分开的2个层次,虽然我很赞同你的观点,我以前的几个项目也是这么做的,但也没有达到必须分开的地步,还是要跟项目的实际需求、项目大小及项目开发资源而定。
Action是表示MVC中的Controller,我觉得你真的应该去看看书了,可能你很牛B,不需要看书,但是我还是劝你翻开《Struts2 in Action》的37页第7行看看。  Action它本身没有任何控制的行为,何来控制可言, 即使你实现了一层抽象的Action加了一些控制进去,那它也只是Model+Controller的一个合体而已。

关于过度设计,我的帖子上也只是说有过度设计之嫌,我也只是在呼吁“编程应该尽可能简单”的敏捷开发思想而已。。




downpour 的回答一看就是很有经验的人。struts2在整个SSH架构中的确是Controller,负责消息转发。
269 楼 gtssgtss 2011-01-07  
IcedCoffee 写道
lpn520 写道
jasph77 写道
构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置,你还是一个普通的程序员。
架构师也是个人,他的架构必然也有不完美地方。

最讨厌那种,整天说这个不好、那个行,自己又没解决方案。


给你看看我之前做的解决方案,同样“添加删除修改查询”,同样是Struts2+Spring+iBATIS+ExtJs

前端
helloWorld.jsp       //用过Ext的都知道,页面是不需要写HTML代码的,所以helloWorld.js直接可以省掉,直接把js写在jsp文件里,还有用EXT直接使用原生态的,封装一层只的很恶心

业务层
HelloWorldAction.java     //struts2的Action,本身就是动作的意思,为什么它不叫Controllor呢,因为控制类已经在它内部封装好了,你实现了Action接口,只要在类里写业务就可以了,再加上struts2每个请求可以对应到Action的一个个方法上,所以万恶的HelloWorldServer.java和HelloWorldServerImp.java可以去掉了

DAO层
再讨论一下DAO层,我们用了ibatis框架,他本身就是个DAO层的实现,你每个SQL调起来就像调用DAO里的每个方法一样,所以HelloWordDao.java就可以去掉了,像HelloWordDao.java里的每个方法就一条代码,有意思吗
所以只要下面两个文件就可以了
HelloWord.java          //HelloWord表的ORM的对象
HelloWord.xml           //HelloWord表操作的SQL语句,ibatis的sqlmap


无语了..那干脆dao也去掉,放进action算了...


很多时候就是可以这样,建议看看oschina掌门人写的“Spring 事务管理高级应用难点剖析”
268 楼 chenjunxt 2011-01-07  
楼主的经验应该不多吧,分层的作用还没弄明白,碰到的问题还比较少,碰到的问题多了,自然就懂了
267 楼 mdsp25xhm 2010-10-29  
优点:细分层,明确各个层次对应的处理类,方便维护。
缺点:开发效率底,项目文件繁冗。
266 楼 suciudeman 2010-10-11  
兰州小菜,helloworld.jsp也不该写,完全可以用template.jsp代替,heolloworld.js,helloworldaction.java 通通可以用模板替代的,真正意义上只用个url传些参数就可以了。
265 楼 okjesse 2010-10-03  
分层的多少应该取决于业务,当你能确定业务和业务的可变范围时,应该把层次尽可能减少,因为在增加层次的同时也会增加代码的可读性和复杂性。如果你确定了业务可变范围了,如你所说,只是简单增删改,对框架的质疑我觉得楼主你是一百个对的。
但有些项目会有二期三期维护,可能会有很多变化,这时候多些层次会对后期修改带来很多便利。这个时候其实可以把这些层次看作是预留接口的作用。
264 楼 BruceXX 2010-10-02  
兄弟,你思想还是太浅了。
263 楼 mercyblitz 2010-10-02  
downpour 写道
不想再引起额外的口水战,对于这种早有结论的讨论,没有任何意义。我会向管理员申请锁定,不要让错误的讨论继续误导大家的思维。


首先,很多人没有把帖子全部看完,很早的下结论。讨论的目的不是要引起什么口水战,而是开放思维大家讨论,在一定程度上对人都与好处,当然不免会影响部分初学者。以理服人,大家都是公平的。

开发没有什么定式,如果说JSP页面不能写Java代码是Java的习惯的,那么RoR或者ASP是不是没有存在的必要呢?

模式是双刃剑,看场景分情况,如此而已。


262 楼 xhdwell 2010-10-02  
lpn520 写道
hjb1029 写道
说到底,楼主还没理解mvc真正的含义,丢恒生的脸啊。

可能我需要向您学习,但请你说话还是别太绝对, 我曾经自己写了一个轻量级的MVC框架, 丢不丢恒生的脸, 不是你说得算。。。

我觉得这个问题拿出来讨论很好啊。一开始看这贴也觉得楼主好菜,但随着讨论深入发现问题远远没想象中的简单,很多我们认为理所当然的概念如果你深入讨论下去就会出现很多疑问,这才是创新的前提。
261 楼 fsword 2010-10-01  
这个话题已经讨论的很长了,我另外开了一帖把话题集中在分层的原因上,欢迎参与
260 楼 downpour 2010-10-01  
不想再引起额外的口水战,对于这种早有结论的讨论,没有任何意义。我会向管理员申请锁定,不要让错误的讨论继续误导大家的思维。
259 楼 mercyblitz 2010-10-01  
downpour 写道
lpn520 写道

通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。
我大概的总结一下:

前端:
helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。

DAO层:
其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。

Service层:
目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。





这种分层开发讨论的帖子,应该出现在05年以前,现在再来讨论,并且讨论了25页,实在是让人觉得是一种悲哀。我把帖子投到新手区,希望楼主更多的思考。



兄弟,你说的悲哀。只能说明你参加工作早,先看到这些东西,你要知道有很多新人进入这个行业。为什么不能讨论?

再说,你首先没有看前面的讨论内容。

downpour 写道

1. DAO层被证明是可以简化的,至少会一个非常薄的层次。在绝大多数的情况下,DAO层是可以省略的,或者使用一个GenericDao的通用设计即可。 Javaeye上已经出现过很多通用DAO的尝试,并且非常成功,楼主可以去查找一下。但是当项目成倍扩张后,DAO作为一个独立的层次就显得比较有必要,因为独立的DAO能够从类和接口声明2个不同的角度诠释一个调用的逻辑含义。

2. Service层和Action层被证明是必须独立分开的2个层次。将2个层次分开的原因很多,其中一个重要原因是Service层将被用于事务的隔离,而Action层是不适合作为事务配置的层次。Action是表示层MVC中的Controller,而Service是业务逻辑层的接口表述,所以这两者的职责是完全不同的。把逻辑全部放到

3. 从你们使用EXTJS的情况看,这个与JSP同名的文件的本意可能是用于渲染页面的。这个是否是过度设计要视项目的情况而言。


1.泛型DAO?只能说在ORM的帮助下,可以抽象出一个DAO用于简单的,楼主不是初学者。复杂的查询没有什么用。

2.职责单一是没有错,但是要分情况考虑,不一定需要提出业务逻辑到Service,给一个理由为什么不能把事务放到Action里面。再说Struts这个东西,Action可以为Model或者Controllor,要看Service是否需要公用。比如,只有一个查询工作,难道还要提出一个Service出来?

3.这个是很简单的问题,HTML作结构,CSS管样式,JS控制行为。分离他们是为了不至于为了其一,而重新编译页面,一般生产环境是不开放及时翻译和编译JSP的。





258 楼 lpn520 2010-10-01  
downpour 写道
lpn520 写道

通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。
我大概的总结一下:

前端:
helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。

DAO层:
其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。

Service层:
目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。





这种分层开发讨论的帖子,应该出现在05年以前,现在再来讨论,并且讨论了25页,实在是让人觉得是一种悲哀。我把帖子投到新手区,希望楼主更多的思考。

我可以简单回答你的几个困惑。

1. DAO层被证明是可以简化的,至少会一个非常薄的层次。在绝大多数的情况下,DAO层是可以省略的,或者使用一个GenericDao的通用设计即可。Javaeye上已经出现过很多通用DAO的尝试,并且非常成功,楼主可以去查找一下。但是当项目成倍扩张后,DAO作为一个独立的层次就显得比较有必要,因为独立的DAO能够从类和接口声明2个不同的角度诠释一个调用的逻辑含义。

2. Service层和Action层被证明是必须独立分开的2个层次。将2个层次分开的原因很多,其中一个重要原因是Service层将被用于事务的隔离,而Action层是不适合作为事务配置的层次。Action是表示层MVC中的Controller,而Service是业务逻辑层的接口表述,所以这两者的职责是完全不同的。把逻辑全部放到

3. 从你们使用EXTJS的情况看,这个与JSP同名的文件的本意可能是用于渲染页面的。这个是否是过度设计要视项目的情况而言。


看了你的评论,我真的,很怀疑你没有认真看我的帖子,或根本没有理解我的本意。
对于开发分层,我只能说现在的分层太形式化了,我只是想革新现在这种过于形式的编程而已。
至于说帖子应该出现在05年以前,我很遗憾的告诉你,05年我还在读书, 至于现在来讨论有何不可呢?技术本来就是一种更新换代的东西,不是一成不变的。
至于希望我更多的思考, 其实我也想叫你思考:据国外的某机构统计,现在的JAVA的B/S开发生产率远不如PHP,可以说JAVA占尽的优势,可会出现这样的结果,这是为什么呢? 你不觉得这个才是悲哀吗?像你这种这么不给晚辈空间的人,以后你儿子可能也会成为你的悲哀。。。

看了你帮我回答的几个困惑,我非常感谢,1、3 这两点我的总结已经写的很清楚了。
关于Service层和Action层被证明是必须独立分开的2个层次,虽然我很赞同你的观点,我以前的几个项目也是这么做的,但也没有达到必须分开的地步,还是要跟项目的实际需求、项目大小及项目开发资源而定。
Action是表示MVC中的Controller,我觉得你真的应该去看看书了,可能你很牛B,不需要看书,但是我还是劝你翻开《Struts2 in Action》的37页第7行看看。  Action它本身没有任何控制的行为,何来控制可言, 即使你实现了一层抽象的Action加了一些控制进去,那它也只是Model+Controller的一个合体而已。

关于过度设计,我的帖子上也只是说有过度设计之嫌,我也只是在呼吁“编程应该尽可能简单”的敏捷开发思想而已。。

257 楼 downpour 2010-10-01  
lpn520 写道

通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。
我大概的总结一下:

前端:
helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。

DAO层:
其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。

Service层:
目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。





这种分层开发讨论的帖子,应该出现在05年以前,现在再来讨论,并且讨论了25页,实在是让人觉得是一种悲哀。我把帖子投到新手区,希望楼主更多的思考。

我可以简单回答你的几个困惑。

1. DAO层被证明是可以简化的,至少会一个非常薄的层次。在绝大多数的情况下,DAO层是可以省略的,或者使用一个GenericDao的通用设计即可。Javaeye上已经出现过很多通用DAO的尝试,并且非常成功,楼主可以去查找一下。但是当项目成倍扩张后,DAO作为一个独立的层次就显得比较有必要,因为独立的DAO能够从类和接口声明2个不同的角度诠释一个调用的逻辑含义。

2. Service层和Action层被证明是必须独立分开的2个层次。将2个层次分开的原因很多,其中一个重要原因是Service层将被用于事务的隔离,而Action层是不适合作为事务配置的层次。Action是表示层MVC中的Controller,而Service是业务逻辑层的接口表述,所以这两者的职责是完全不同的。把逻辑全部放到

3. 从你们使用EXTJS的情况看,这个与JSP同名的文件的本意可能是用于渲染页面的。这个是否是过度设计要视项目的情况而言。
256 楼 cn-done 2010-10-01  
原来大家都纠结在框架分层设计上了。其实本人的观念是框架不能单纯的从技术角度出发,需要结合业务,具体的场景才能设计出复合当前项目开发的框架。楼主提出的问题,也是现在开发分层的通病,有点教条主义了。没有全能的框架,简单易用、高效才是硬道理。
255 楼 grave 2010-10-01  
我想那个hello world人家也是那你了解一下框架而已,跟过度设计有什么关系吗,这个hello world只是为了展现一些编程上的契约,跟具体实现的功能无关。
254 楼 peterwei 2010-10-01  
abiandbel 写道
看到有个同学说的不错。

是到了我们做java的去好好看看ROR的时候。
跳出来去看看,对我们做Java的也有好处。

ROR为什么没有接口?
ROR有所谓的分层么?

ROR在敏捷开发方面比Java好在哪里?或者坏在哪里?
ROR在领域驱动设计开发为什么能比Java做的好?

这些问题我们应该试着去寻找一下答案了。

恩。。。的确是到跳出Java,去看看其他语言或者架构的时候了。

哈哈,这个说的。跳出Java,到RoR,人家在Java优势,为什么用ROR?就像Java的人让C的搞Java一样。很多东西,说白了就那么回事。人在江湖,身不由已。
253 楼 peterwei 2010-10-01  
<div class="quote_title">lpn520 写道</div>
<div class="quote_div">
<p>通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。<br>我大概的总结一下:<br><br>前端:<br>helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。<br><br>DAO层:<br>其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。<br><br>Service层:<br>目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。</p>
<p> </p>
<p> 当然是需求及成本,业务复杂度等各层面决定是否需要Service层。没有一招吃遍天下的,具体情况具体分析。</p>
</div>
<p> </p>
252 楼 abiandbel 2010-09-30  
看到有个同学说的不错。

是到了我们做java的去好好看看ROR的时候。
跳出来去看看,对我们做Java的也有好处。

ROR为什么没有接口?
ROR有所谓的分层么?

ROR在敏捷开发方面比Java好在哪里?或者坏在哪里?
ROR在领域驱动设计开发为什么能比Java做的好?

这些问题我们应该试着去寻找一下答案了。

恩。。。的确是到跳出Java,去看看其他语言或者架构的时候了。
251 楼 lpn520 2010-09-30  
<p>通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。<br>我大概的总结一下:<br><br>前端:<br>helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。<br><br>DAO层:<br>其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。<br><br>Service层:<br>目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。</p>
<p> </p>
<p> </p>

相关推荐

Global site tag (gtag.js) - Google Analytics