反SSH架构，我开发J2EE项目为什么只需要一层就足够了

   有些话想说很久了，一直忙于工作和学习，很少写博客，今天下午天气晴朗，楼下很多小孩子在打篮球，自家的也睡午觉去了，一个人在书房里很惬意，暂时从繁重的工作中抽出心情来放松一下，把自己心中想说的话整理成文字表达出来，可能很多人听得不中意，要批评一下我，我会很虚心接受的。

我做J2ee开发也快9年了，加上1年的DELPHI，我的程序员生涯也有十年了，我做了不少J2EE的项目，从物流ERP，进销存ERP或电子商务之类都做，最长的项目做了5年，最短的做了3个月。我在2005年spring兴起的时候就一直关注它，现在2011年SSH已经大行其道，很多J2EE同行都认为现在这么流行SSH而不用是不可想像的。持这种看法的同行越来越多，我也跟很多同行刨根问底地讨论这个问题，我在此想表达一些我的观点和实践。请大家给点热烈的反对掌声，谢谢大家。
1.spring的xml配置太多，发生错误难以调试，程序员都成了配置工人了。
2.在tomcat中启动spring要花20秒以上，加上Hibnerate，启动时间在30秒以上，可怜java不是php或asp.net，人家改了后台代码是不用重启的，而我经常因为增加或删除了一个java的方法而需要重启，一天至少要重启tomcat10次，最多会超过30次。次数多了就烦人。
3.spring在单元测试时要加载和hibernate的所有配置，每次加载都要30秒，曾经统计过一天需要跑100次单元测试，浪费了大量的时间在等待启动，为此我很少写单元测试。
4.Spring的AOP配置我到现在还没学会，一看那几十行的xml配置，我就怕了，不就是记录系统日志和方法调用嘛，用得着AOP吗？而且我查找AOP所拦截Serivce的方向日志，数量大得惊人，如大海捞针，有意义吗？有价值吗？
5.spring配置Quartz挺麻烦的，我花了一天时间去配置，花了一天时间去找错，问题虽然解决了，但是现在还偶而看到有人问Quartz配置出错怎么办的问题。其实，我就写了个EasySchedule.java实现了quartz的定时执行功能，也只是花了5个小时就完成了，很实用，经常用到，我上传了，大家有兴趣可以看一下。
6.Hibernate启动加载配置大约要10到30秒，我曾经做个大中型项目用到200个表，100多个视图，后来改用hibernate之后加载时间长达30秒以上，偏偏开发经理很注重单元测试，每次跑都要等30秒，痛苦得不得了，跟经理上诉无效，也找不到延迟加载的方法，单独自定义加载POJO的做法太机械了，为此我不想再浪费生命选择离开公司，听说现在这项目一直招不到合适的程序员来维护，旧人全走光了，新人也干不长，这Hibernate不是害人吗？
7.Hibernate的一对多多对一关联配置和hql听起来不错，用起来还是很有成本的，也很死板，耗内存，N+1等性能问题还是要手工解决，对于新人来说要掌握的太多，能用好的不多。而且做报表时hql极不好用，基本上都会用sql做报表或复杂查询。但有经验的程序员都知道sql不好维护，所以，hql并没有解决问题，而是增加问题。
8.hibernate打印sql的参数的?号问题，做得太差了，我现在是用p6spy或jdbcdslog解决sql的日志问题。但是那很长的select column1 as columns_1...的问题，就无法解决了，看得让人不爽。
9.hibernate的没有提供ORM查询类，就因为这个，所以才有dao类存在的理由，我所说的查询类，大家可能不太理解，举例来说，我需要一个查询职员列表，条件是05年入职的有效男性职员， 那我期望会有以下语句实现查询：
StaffSelect staffSelect=new StaffSelect(conn);
staffSelect.setValid(true).setJoinDate(2005,2006).setSex('男');
StaffResultSet rs=staffSelect.toStaffResultSet();

这个ResultSet有许多实用的方法为你节省了写代码的时间，例如
输出的有：toList(),toXml(),toCsv(),toExcel()等，
处理的有：filter("sex=男 or age>50"), union(otherRs), sum(fields...), sort(fields...)等。
我想如果查询可以这么简单，就Action一层就足够了。当然，如果需要重用的话，放到Serivce层会好一些。
10.分Action，Service，Dao三层，并且Service层还有分接口和实现类的问题：
10.1.在查询上Action和Service层几乎都是做转发，带来的问题是参数传递不灵活，service和dao层不能很方便地得到Action层的参数，本来很简单的问题因为分层而复杂化了，而且为此还要在spring配置一堆bean，重构时还麻烦一个个改配置。如果这个dao只是被一个serive调用，这个service只是被一个Action调用，这三个类在外部都没有重用的价值，配置的内容比具体代码还多，那还搞个Service接口干嘛，还分成三层干嘛。
10.2.在提交修改上，数据保存很少重用的，只要写一个通用的保存处理就足够了，如有业务逻辑，那就在Action层写，然后super.save()，把余下的部分交给父类处理就好了，这么简单的处理，有必要分三层吗？
10.3.在报表处理上或一些业务逻辑处理上，如有分层的需要，那应该从业务逻辑去分层，实现类的更高的重用性和封装性，而不是SSH这样固定（也叫规范）的物理方式去分层。
11.用一个标准的SSH三层框架写后台，经比较，代码量是只有一层框架的4倍，主要是配置文件和配置类过多，中间有太多的转发方法。一个新人学习j2ee，花费大量的时间在配置上，而没有很好的提升业务理解能力和逻辑算法能力，一般来说，一年经验的j2ee程序员是刚熟悉SSH的配置，三年经验的非常熟悉配置，但是真的去让有经验的j2ee程序员去写核心的代码，还是有太多的问题。很多J2EE程序员的基本功不扎实，这是我面试别人时发现普遍的现象。

   j2ee的复杂是人为造成的，这些复杂性为项目的成功埋下了隐患，j2ee的复杂是很多因素造成的，往往是被利益所驱动，而不完全是符合事实和程序员主观意愿的。很多大公司都宣传自己的技术框架多么的规范，标准，我觉得这些都是虚的，做为了一个合格的程序员，应该更多的从客户需求，市场价值去看待自己的工作，关注客户真正的想法，而不是为了自己的技术喜好，职业发展而选择复杂的技术去解决问题。程序员的思想应该是创造性的，应该用简单的方式解决复杂问题，我们的价值在于为客户解决问题，而不是为自己制造麻烦。

   我很认同一个同事曾经说过的话，现在做开发其实并不复杂，如果你觉得很难，那很可能是方向错了。。。

评论

19 楼 sarahtest 2012-07-09  

但用的人很多，公司用这个架构，后来者还是要学啊

18 楼 xiaokang1582830 2012-07-05  

支持lz的想法

17 楼 jahu 2012-06-29  

经典。。。学习。初学者没什么好学的。只有学习

16 楼 uule 2012-05-05  

少个Tools和EasyMath工具类。。。

15 楼 hut 2012-04-22  

ffychina 写道

但我认为现在j2ee的框架还能改进的地方太多了，框架都是半成品，要让他们变得顺手还要下很多功夫，而JAVA程序员最大的乐趣不应该是学习和配置，而更多的应该是创造和改进。

我认为现在J2EE的框架不是因为半成品，是框架们野心都太大了，什么都包含进去，什么都要做全。应用环境越多，复杂度就越高。我现在都是先看框架源代码，取核心的内容，自己实现，调用起来更简单。我真希望现在的框架简单些，专一些。

14 楼 hut 2012-04-22  

楼主说到我心坎上了。我是从2003-2004年 spring1出来时就开始用SSH这一套东西了。当时spring号称轻量级的J2EE，狂批EJB2,对什么DI,AOP深信不疑，还深入研究过spring的源代码。到SSH2出来后就不怎么用了。对多得要死的配置文件深恶痛绝。spring也越做越复杂，越做也庞大，类的依赖关系也越来越多。感觉比当年的EJB2还要更重量级了。目前跟你一样，不用spring，不用hibernate，越简单越好。

现在来应聘的，个个都只会SSH框架，我想招几个熟悉多线程，socket方面的人都招不到，唉。

13 楼 minn84 2012-03-02  

tyzqqq 写道

第一，鼓吹的人太多，大多数冒泡还不会，就整天搞架构．
第二，许多人认为工作在于折腾，不折腾怎么能有事，怎么好意思拿工资．

12 楼 tyzqqq 2012-03-02  

第一，鼓吹的人太多，大多数冒泡还不会，就整天搞架构．
第二，许多人认为工作在于折腾，不折腾怎么能有事，怎么好意思拿工资．

11 楼 ffychina 2012-02-26  

我也想把系统分拆成多个子系统，但是现实的情况是不允许的，系统之间如何相互调用就很复杂了，用EJB或SOA的话，估计不是慢，而是很慢。而且系统已经运行了5年以上，这么多数据和逻辑在上面，是没有人敢动它的核心的，也没有时间动。所以尽管系统性能再差，测试难度再大，开发效率再低，维护再麻烦，都会惯性的继续下去。
我几年前维护的一个ERP系统，系统功能不断膨胀，需求不断更改，但这些都不是最麻烦的，最麻烦的是spring配置关系越来越复杂，xml配置又无法充分利用eclipse重构，即使是一些简单的业务逻辑修改也要同时要修改xml配置和java类和接口，因为数据表+视图接近300个，因此还要等待30~60秒的tomcat启动速度（64位服务器30秒，开发机器要60秒），真的是让人抓狂。所以这是我不喜欢ssh的根源。
直到现在，我仍没有更好的办法解决这个复杂系统所面临的维护成本过高的问题。我不知道各位朋友处理过的系统有多复杂，涉及的表和视图超过200的有多少，在超过200多个子功能的系统中，如果用到Spring和Hibernate，是否有我相同的困惑，又如何解决呢？
我现在维护的系统没有用到spring和hibernate，但因为硬件复杂和安全性的原因，编译要5分钟，重启也最少也要3~5分钟，真是让我很抓狂，除了等系统启动就是等发工资了，怎么老碰到拿时间来换金钱的事呢。
不知道各位所做的项目有多少是开发有多少是维护，是否都面临跟我一样的问题，给的时间太少，要实现的功能太多或要fix的bug太多，客户很会来事搞些需求变更挑战你的EQ和IQ，一些性能问题更搞得人焦头烂额，项目进度总是绷得紧紧的，每天加班都是家常便饭。当然，喜欢混日子的程序员估计这辈子很少遇到我这种情况。
但是在我自己完全主导的6个J2EE项目中，不用spring和hibernate（但struts2感觉不错，留着），自己写ORM框架，写后台框架（代替spring），写工作流引擎（兼容JBPM4），以重约定轻配置，减少重复机械工作为目标，让团队都把精力都放在业务层面上，抽出更多的时间把需求分析和质量测试做好，整个项目就能做得很顺利。
尽管很多人都认为已有的框架已经这么成熟，没必要重复造轮子。但我认为现在j2ee的框架还能改进的地方太多了，框架都是半成品，要让他们变得顺手还要下很多功夫，而JAVA程序员最大的乐趣不应该是学习和配置，而更多的应该是创造和改进。

10 楼 finallygo 2012-02-25  

ffychina 写道

谢谢finallygo这么详细的见解，补充一下为什么用20s，是因为hiberate的xml与spring的xml加在一起大约200个xml左右吧，开发机器是E2160。
我很享受不用ssh的tomcat启动只要3秒的那种快感。
或者用spring自然会发现它的好处，不用spring自然会找到相应的解决办法。我希望java能够更轻盈一些，不要让框架影响我们的创造力。
相信不用spring做J2ee项目的人已经很少很少了，但我仍然相信我的想法是对的。

汗,这么多文件的话,那肯定慢了,建议你们把项目进行拆分,更加业务拆分成小的项目,这样就不会这么臃肿了,"启动只要3秒的那种快感"我也很享受,我也希望能快速的进行测试,其实针对这个问题,我之前自己还想写一个替代ssh的框架,只是到后来才发现自己的水平还是有限,你说的也对,不用spring也可以有相应的解决办法.spring的两个重要的概念ioc,aop其实也是在别人的基础上发展起来的,而我们用spring框架更多的是提高我们的生产效率,因为它提供了非常多实用的工具类,比如XXXTemplate,同时我也"希望java能够更轻盈一些"

9 楼 ffychina 2012-02-25  

谢谢finallygo这么详细的见解，补充一下为什么用20s，是因为hiberate的xml与spring的xml加在一起大约200个xml左右吧，开发机器是E2160。
我很享受不用ssh的tomcat启动只要3秒的那种快感。
或者用spring自然会发现它的好处，不用spring自然会找到相应的解决办法。我希望java能够更轻盈一些，不要让框架影响我们的创造力。
相信不用spring做J2ee项目的人已经很少很少了，但我仍然相信我的想法是对的。

8 楼 finallygo 2012-02-25  

1.首先,你对ssh启动慢的问题我之前也一直抱怨,但是后来我就没有遇到这种烦恼,主要是电脑的配置好了,也就是说你可以从提高硬件要求来缓解这种问题,还有你说启动spring需要20s肯定是有问题的,像我这种机器很差的电脑,也就5,6s就好了,也就是说,你配置上也应该是有些问题的.如果你想提高spring加载文件的速度是不是可以通过设定懒加载来实现??
2.你说的配置多的问题应该很久之前已经解决了吧,即使是一年前很多项目应该都使用注解了
3.针对你的spring进行单元测试时间长的问题,我想你是不是没有很好的考虑代码解耦合呢?正常来说,进行单元测试的粒度都是非常小的,也就是说可能我只需要加载一个配置文件,就可以进行,而不是把整个项目所有的都加载,另外说一点,如果你们有一些服务或者对象在创建和调用的时候非常慢得话,你有考虑过使用mock的对象来加快单元测试么?
4.Spring的AOP配置的配置多是为了更好的扩展性,你仔细研究下就知道了,还有你对为什么使用aop的理解还是有些肤浅,为什么我们使用aop,是为了让我们更好,更方便的进行扩展而对原来的代码不进行修改,让我们在功能扩展的同时,代码的简洁性依然能得到保障,不是说,你现在是用到了日志功能,就认为它只有这个功能,比如你某天需要记录所有方法的时间,或者说要做统一日志处理的时候,你怎么办??其实,你想想j2ee中得filter就可以很好的理解了.还有你说的日志文件大的惊人,是否也可以说明你们对log4j的使用方法有些不当呢??而且就算日志大,也不能和没有用划等号,如果都像你这样想的话,hadoop又是做什么用的??
5.Quartz我觉得还好吧,也不算麻烦,你说你能实现,我也表示肯定,但是我们在实际的场景中还是会选择这种开源的第三方组件的,这个是为什么??因为它稳定,有这么多人用,一有什么Bug就很快修复了,也有社区进行着维护升级
6.hibernate没有怎么使用过,不做评价,不过印象中也有和你一样的烦恼
7.对于你说的不分层,我是不赞同的,分层是为了解耦合,为了复用,具体我就不说了
8.对于接口的认识我和你近似吧,接口滥用不好,是和业务及系统的特点有关系的,盲目的都使用接口确实有时候会出现过度设计

7 楼 ffychina 2012-02-22  

raoliv 写道

看了你的“深圳财富大厦阿里巴巴面试架构师职位的详细过程，实在让我不吐不快”让我感觉阿里是不是业务和技术分的很开，而你比较注重业务分析，看了你这篇文章之后，我觉得你对技术有追根问底的精神，可能是你的学习过程所决定你对SSH的反对，SSH04年开始盛行的，不是11年，我觉得你要对一个东西做评价你必须深入了解它，否则就对你知道的几个优点谈谈看法吧。

谢谢你的意见，程序员都有一个梦想，永远让别的程序员都活在他的代码里。我也不例外。
这篇文章都很久了，我说2011年指的就是那时候，SSH已经非常深入人心了，看着身边的一些同事天天在研究着如何把SSH框架套到项目中，90%的时间都在研究技术，如何用AOP，如果玩一对多关系，如何用好HQL，如果用到二级缓存等，而不是去解决业务上的问题，结果项目严重延时，上线后问题太多而导致客户非常不满意，我才写了这篇文章。

6 楼 minn84 2012-02-21  

个人观点，ssh如果项目较大，会把问题复杂化，后期维护困难，有些功能应尽量不用

5 楼 raoliv 2012-02-20  

ffychina 写道

我所提倡的是程序员要有创造性思维，别在框架上搞来搞去，说到底框架只是半成品，什么都得自己去实现。如果你有OO思想，你不需要框架也能解决问题，如果你真的有水平，就不要在JAVA框架上搞来搞去，来点系统级的解决方案，而不是JAVA语言的层面。OO只是在开发层面上比较重要，但也只不过在整个软件项目占30%不到的份量，而更重要的是客户的解决方案和质量要求，而不是技术。

看了你的“深圳财富大厦阿里巴巴面试架构师职位的详细过程，实在让我不吐不快”让我感觉阿里是不是业务和技术分的很开，而你比较注重业务分析，看了你这篇文章之后，我觉得你对技术有追根问底的精神，可能是你的学习过程所决定你对SSH的反对，SSH04年开始盛行的，不是11年，我觉得你要对一个东西做评价你必须深入了解它，否则就对你知道的几个优点谈谈看法吧。

4 楼 ffychina 2012-02-19  

我所提倡的是程序员要有创造性思维，别在框架上搞来搞去，说到底框架只是半成品，什么都得自己去实现。如果你有OO思想，你不需要框架也能解决问题，如果你真的有水平，就不要在JAVA框架上搞来搞去，来点系统级的解决方案，而不是JAVA语言的层面。OO只是在开发层面上比较重要，但也只不过在整个软件项目占30%不到的份量，而更重要的是客户的解决方案和质量要求，而不是技术。

3 楼 huashuizhuhui 2012-02-18  

复用和易用本来就是一对矛盾；设计模式就是用复杂的设计进行可复用的开发；可能楼主使用的方法还需改进吧；

2 楼 mtnt2008 2011-04-11  

想起了，以前的一句话：“杞人忧天”。现在，就是想的太多了，结果导致更加的复杂。其实，简单使用最好

1 楼 Jathon_hs 2011-04-11  

关键在于用对地方，而不是为了用而用