“过度设计”之真实例子

帖子我写的，也只是说有过度设计之嫌， 我也是提出了设计可以从简， 以及从简的方案

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

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

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

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

 

 

看到有个同学说的不错。

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

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

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

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

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

 

哈哈，这个说的。跳出Java,到RoR,人家在Java优势，为什么用ROR？就像Java的人让C的搞Java一样。很多东西，说白了就那么回事。人在江湖，身不由已。

我想那个hello world人家也是那你了解一下框架而已，跟过度设计有什么关系吗,这个hello world只是为了展现一些编程上的契约，跟具体实现的功能无关。

原来大家都纠结在框架分层设计上了。其实本人的观念是框架不能单纯的从技术角度出发，需要结合业务，具体的场景才能设计出复合当前项目开发的框架。楼主提出的问题，也是现在开发分层的通病，有点教条主义了。没有全能的框架，简单易用、高效才是硬道理。

这种分层开发讨论的帖子，应该出现在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的一个合体而已。

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

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

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



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

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

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