所谓的SSH是指当前最热门的3大开源框架：Struts、Spring和Hibernat，现在最流行的就是SSH的开发模式，现在大部分的做java开发，言必称“SSH”、“框架”等等，好像我们这些老开发要是不会SSH，出门都不好意思跟人打招呼似的。但事实真的如此吗？作为10年以上的老开发者，本人认为SSH固然有它的优势所在，但在各个方面均存在着很多的问题，目前SSH的流行就跟帝都、魔都的房价一样，是一个肥皂泡，无非是大小问题，SSH充其量只是适合小型的，低负载项目，对于复杂的、带有巨大变数的、高负载、高容量的项目，还是必须依靠传统的开发模式和管理方式。
这3大框架的功能和优缺点本文不再赘述，本节主要讨论SSH开发模式的缺陷。
采用SSH开发的主要需求点是避开笨重的EJB，同时能够帮助开发者更快、更方便灵活地对系统进行配置式开发，降低开发的门槛，但凡事都有2面性，本人认为，目前SSH开发模式主要存在问题：

1、 整合复杂，除错困难
3个框架涉及了B/S开发的大部分主要环节，而整个系统一般要涉及web容器、中间件、数据库、其他框架或软件（如表单、工作流、报表等等），需要有1堆软件产品，需要开发人员再在上面框架叠框架，产品堆产品，整合起来实在之复杂，这都给调试、测试、部署等带来了极大的困扰，例如，出现某个页面打开很慢的情况的话，要找问题点的话，那要花得功夫，可就不是一点半点了。

2、 配置文件过多
自SSH开始流行后，java开发就出来了一个很不好的风气，那就是对XML配置文件的无限制使用，本人并不是说XML不好，但凡事总有个度，过度就不对了，XML配置文件严重影响了代码的可读性和连贯性，将很多应该由代码完成的工作割裂开来，这对类似本人这种老开发来说，就好像是吃饭吃的正爽，突然要跑到边上去开会，开了一会儿，又要去吃饭。此外，过多，过于复杂的xml文件会让整个系统的可维护性和组织度下降。
本来SSH的配置文件之多，之复杂，已经是让人欲哭无泪了，再加上其他的框架所用到的配置文件，那已经到了令人发指的地步了，最雷人的是，本人曾经对tapestry颇有好感，因为它能真正分离界面与代码（下面会介绍这种模式），但稍微摸了1把就赶紧扔掉，这玩意儿，每个页面都至少有一个XML文件，为嘛捏？！为嘛捏？！这下把本人雷得个外焦里嫩的，瀑布汗。
本人一直觉得为什么要这么多xml呢？每个框架一个不好吗？往web.xml或者一个公用的xml里面写不好吗？多用“规则”来默认不好吗？xml文件不是兜里的人民币越多越好的。

3、 Hibernaet对系统优化的破坏
讲到hibernat，我是又爱又恨，它原来的目标是代替EJB的实体bean，它的优点在于对象化，但它缺点亦在此。
如果你是做小的demo系统、小型应用系统或者数据负载很小的系统，用hibernat是一个很好的选择，但问题是，如果需要对你的SQL语句调优了，那就抓瞎廖，本人在此强烈建议，如果你的系统数据比较多，比较复杂，而且预计会跑上3年，那就尽量别用hibernat。
其实，本人觉得，用连接池技术，再加上良好的数据结构设计和对数据字典的良好管理，对开发团队来说足够了。

4、 对view方面的支持很差，
按理说，struts是MVC的先行者，本人原以为，它在view方面应该有很多的支持的，但除了taglib之外，并见到其他什么东西，本人等到struts 2后，依然没有发现新意，实在失望啊。
本人一直觉得，java b/s开发最累人的，不是SSH所关注的那些，而是画面与代码没有分离，造成view层面的异常混乱，设想一下，一个jsp里面可能有html代码、java代码、js代码、CSS代码，还有struts的tablib或者其他的什么tag等等，这是何等狗血和逆天的场景阿！