使用SSH这类框架就真的很好么？？

现在好像是个J2EE Web程序都要用到这种东东，不管什么样的系统设计都要用上Struts+Spring+Hibernate
好像成了标准的公式 -_-|||，我想问问大家，大家做了这么多年Web系统，真正可复用、需要解偶合的模块真的很多么？？
XML配置文件泛滥，界面没特点，不够灵活（受框架特点限制），反而我感觉用最普通的HTML（JSP）+JavaBean+jQuery开发要方便、简单的多，来的直接（可能我的项目太小），分工也明确美工直接设计界面，想怎么做就怎么做，怎么表现那是美工和客户的事
设计人员根据务业要求，设计服务接口（都有那些服务，接收什么数据，抛出什么数据）
java程序员实现对应接口
javaScript程序员实现界面和接口服务的整合我说说我对框架的选择过程（可能我接触的项目小，我只说我的这种情况）：
一开始我用的是Struts，没用多常时间，太死板，发现JSF好像要比Struts要好一些，换了JSF，后来JSF也不灵活，太麻烦，后来发现yui-ext框架，发现很Cool，确定了html(yui-ext)+json+DWR+JavaBean这种开发模式，不过开发了一套系统后，感觉ext更麻烦！json数据格式要求太多，不通用，最后发现 html(jsp)+jQuery+json+JavaBean这种模式最好，最灵活这样的好处是：
1.大家想用什么开发工具没有限制（现在我们组有用Netbean也有用Eclipse的还有用DW之类的）；
2.分工明确，成员要求学习掌握的东西最少，相互不冲突；
3.以后的维护、二次开发对技术人员的要求也最少，可大大降低人力成本；
4.学习了解系统结构最简单，不需要看配置文件等，清晰明了，培训成本低；
5.界面可以做的很漂亮，表现形式不会千篇一律
大家感觉呢，我感觉要比SSH这种类型的开发好很多？欢迎拍砖

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

对了，还有一点我想说：“如果你选择一种框架，可能过一段时间你就会被淘汰，新框架、新技术对开发人员冲击太大，不如回归本质，就是javaScript和javaBean(JSP)，专著业务，感觉才是上上之策”不过反过来说，如果你不会SSH这类框架的使用，在中国这种浮燥开发环境下，根本都找不到工作
那种开发方法适合你那种就是最好了。
>>5.界面可以做的很漂亮，表现形式不会千篇一律这个观点就是扯淡。完全一帮没有思想的人再垒代码。
根据项目的情况来。
SSh 轻量级开发，使用简单原始的 Java 对象（POJO）编程。在业务领域，轻量级开发节省时间和金钱。
EJB 的重量级面向组件模型。
各有各的的好处，不能一概而论。
哪个也没有限制你用什么工具，想用什么就把那一堆jar包拷过去，你们组的这种方式，也就是开发时候玩玩，后期够你们受的
这就和讨论java EE 开发为什么要分层一样。你把所有代码都写到JSP里不是更简单，用什么框架不重要，主要是看它能不能给你带来效益。
原来是95在谈JAVA....不管是STRUTS还是融汇了WEBWORK的STRUTS2, 我都没有在正式项目中用过..
只属于那种没有吃过肉却看见跑那种...
其实偶就不是JAVA程序员...偶本想说是路过打酱油地...
从来没真正写过Web应用，就不发表意见了，仍然忍不住想说几句
老实说，我也觉得SSH过于臃肿...
SSH  .......   是啥东东。
这帖子只是说，现在有些软件公司把SSH看得太重了，什么都是这套架构组合，以经到了病态的地步 Orz
...ssh是看情况的吧。。
框架是为了简化工作提高效率
你需要哪个就哪个没规定要全。。你也可以spring+javabean+jsp ，spring+struts+ibatis
spring+jsp+javabean+ibatis,spring+webwork+ibatis我个人认为在项目spring 不可缺少。。其他的就看情况还有楼主说美工就做美工的有些界面是在运行期才有数据显示的美工做不了的
自己去写，后期维护的成本要大很多，也不太容易扩展。
万一扩展功能，郁闷死你。
当然是用框架也不一定就是ssh了
hehe  也有一些道理但不会确实不是很好找工作啊呵呵几乎每个公司都问到  会不会使用xxx框架
用框架是对公司有利益，如果用 jsp +  servlet + javabean  新人来后业务理解起来比较麻烦。通过框架就比较方便了，为公司节省了成本。  同样也会节省后期的维护成本。
个人觉的ssh用起来比较方便，特别是Spring中的IOC（依赖注入）及AOP做事务处理方便方便
老实说我觉的ssh并不好！框架在一定程度上大大的限制了程序员的创新能力！而且ssh并不完整！有着太多的缺陷！对于错误处理这方面我觉得就是不行！远远没有net的容易理解！java开源，而ssh则违背了这点！所以我觉得ssh的推出有可能使java倒退！但是也许有高手可以全盘否定这些规定也未知的！所以我觉的struts可以用用，但是hibernate和spring如果用不好就不要用了！我自己个人想法。
楼上我也一些同意的看法!其实我个人认为在3个框架中,做得最成功就是STRUTS!!
我并不喜欢用hibernate，hibernate是为大型项目量身订做的。这里所说的“大型”，本不是指模块多就叫大，而是数据量大，性能要求高，主要任务在数据库端的项目。如果用hibernate去做多表查询，简直就是自己跟自己找麻烦，还不如用spring的jdbcTemplate。hibernate的优势就在于做简单查询。
那有人要问，项目中确实有多表查询，或很复杂的查询怎么办？我刚才已经说了，hibernate并不适合做这些工作，而是在大型项目中，将这些操作都放在数据库端完成了，我打个比方说明。
比如做信用卡的系统，你先刷卡消费了200元，然后套现500元，刷卡是在20号以前，套现是在20以后，那么在你的总金额中就是700元，但本期还款只有200元，同时要计算出本期应还款多少，最低还款多少，同时在你总欠款中还要显示套现的手续费，利息。这时，如果用hibernate去直接查询，那简直是做恶梦，不要说做不出来，就是做出来了，性能上也叫人吐血。怎么办呢？通常是这样处理的，数据库在夜晚2点钟的时候会自动开启一个存储过程，来计算这一切数据，然后将结果写入另一张“结果表”中，为安全起见，在“结果表”上会加一个视图，这样hibernate只直操作这张视图就行了，这就纯粹多了。
因此对hibernate，我的看法是慎用，否则你就是自己跟自己找麻烦。对用数据库不大，且多表查询很多的情况下，就用jdbcTemplate或原生jdbc API即可。
SSH是有缺点，不过，建议说SSH一无是处的人去把SSH的源码阅读一遍，再来发表观点。
既然SSH大流行，那么自有它流行的道理。（优点太多，略）
既然都流行到成为行业标准的话，用它们那么后来人就能在很短时间进入项目。
不能光开发时风流快活，也要想想后来者的感受。
一直学习，却实际项目中从来没用过，我有些怀疑SSH是不是真的那么流行？是不是只供学习？
要始终相信社会是进步的，不会回到原始社会，感觉java东西太多了，不懂，就是不懂，还是不懂。
java的东西确实很多，这可能就是开源的弊端，国外的企业为了自己的利益就不停的包装java然后推出新的技术，其实感觉这些东西根本就不是技术上的需要（即使需要也不能有这么多标准啊），而完全是商业上的恶性竞争所至，所以苦的只有开发人员而已啊
SSh有好多好处，就不再多说。但使用框架后，发觉也有点不习惯的地方。像通超链接转到一个新增记录的页面，其中包含一些下拉框，而数据是从DataBase出来的。在以前（先不考虑使用AJAX），则会用JavaBean，在页面使用EL和JSTL生成。而在使用SSH后，要么额外写一个JavaBean，但这样却得不到SSH的优点。要么就将超链接指向一个Action，由Action中向相应的ActionForm加入下拉框的数组，或者列表，再使用Struts的标签绑到相应的下拉框。的确有点麻烦和不习惯。但整体的MVC结构还是比较整洁，统一。不使用框架的好处自然是代码的写法比较自由，无拘无束，但后期要维护这部分也需要多一份心眼。当然，即使不使用框架，代码也可以写得很条理，而这本来就是程序员必需做的。但如果有得选择，使用SSH再加JQuery或者DWR也可以做到类似JavaBean+纯JSP的效果。这完全是项目的决择。如果一个公司不要求懂任何框架，这对程序找工作也是一件易事，值得提倡。嘎嘎~~
SSH，后期维护很方便啊，而且界面方面可以使用ExtJS等等啊，并不需要美工！
呵呵解决问题才是实际.邓小平说了,实践是检验真理的最好标准.我根本没有用哪行ssh框架,也没有用struct.我的模式也可以说是框架是自己造出来的.　我们公司的需求是这样的:　公司要求每天定期或不定期的要查询各项费用报表,或通道数据报表.
我写了一个mailProxy后台服务　;后台数据库我不管.是具体搞计费区分运营的同事维护.但我要把数据内容展现出来.且这些数据都是变得的.不同的需求对应不同的sql.我这样设计的.　我的后台服务一启动是一组java 程序jar ;作为开机服务启动不会停止.　他们一有需求,或通过job方式每天定时下方任务到我对应的tb_mp_mt表　我后台扫描到该表;每条记录作为一个任务对待.　记录中包含了to目标邮件列表或群组　;还定义了一个dataSRC 字段　就是放他们要展示数据的sql　当然是job提前生成好的.我的模块会自动讲其翻译成Wap2格式作为邮件发送出去.且支撑wap2登陆查看.一个模块俩用.一个模块n用.对应n个需求.这就是我的模式.
我觉得不管用不用 SSH都是值得学习和掌握的里面的一些思想基本的方法即使最后不用这个或者换用其他的框架甚至其他的语言都是可以用到的特别对于我这种费计算机专业的来说。。感觉学了SSH以后对这些东西的理解更进一步了
以前做过PHP 如果习惯用JSP+JAVABEAN开发不如转做PHP更好一点
不要太依赖于框架了，现有的框架对于解决一些简单的问题还是比较有效的，但是我没有碰到过一个项目能够在现有的框架之内能够完全解决的，到了最后，框架反而成了制约，很多复杂的问题在框架之内都是无法解决的，往往只能绕开框架的限制来解决的了，这样下去，整个最后就变得四不像，因此对框架的使用，越是简单越好，而且只能适度的使用，比较只采用STRUTS1、2/Spring来实现servlet那一层的接口就足够了，后面的业务逻辑层、数据库层自己来实现，只要能够保证层次很清晰、减少层次之间的耦合性，那就是很好的设计了；反而，无论是Hibernate、EJB，在早期是能够解决不少的问题，但是到了后面就成了制约因素了，而且无论是Hibernate还是EJB都不是不可或缺的东西
ssh 框架的整合很好，对于大一点的项目很好维护和开发，
用这个框架来开发项目，思路也清晰
ssh 框架开发也是为了项目开发的规范和标准
SSh有好多好处，就不再多说。但使用框架后，发觉也有点不习惯的地方。像通超链接转到一个新增记录的页面，其中包含一些下拉框，而数据是从DataBase出来的。在以前（先不考虑使用AJAX），则会用JavaBean，在页面使用EL和JSTL生成。而在使用SSH后，要么额外写一个JavaBean，但这样却得不到SSH的优点。要么就将超链接指向一个Action，由Action中向相应的ActionForm加入下拉框的数组，或者列表，再使用Struts的标签绑到相应的下拉框。的确有点麻烦和不习惯。但整体的MVC结构还是比较整洁，统一。不使用框架的好处自然是代码的写法比较自由，无拘无束，但后期要维护这部分也需要多一份心眼。当然，即使不使用框架，代码也可以写得很条理，而这本来就是程序员必需做的。但如果有得选择，使用SSH再加JQuery或者DWR也可以做到类似JavaBean+纯JSP的效果。这完全是项目的决择。如果一个公司不要求懂任何框架，这对程序找工作也是一件易事，值得提倡。嘎嘎~~
ssh只是一种设计理念，不一定完全使用这个框架，成熟的设计者都是采用ssh中的部分功能，根据自己的项目需要，添加适合自己的应用。
我认为楼主进入了一个误区。框架的主要作用并不是简化你的开发过程，虽然在有些时候它确实提高了开发的速度（这种提升多是因为框架的基本结构几乎在所有的应用里都差不多，节省了基础结构设计的时间，可以直接开始配置系统大环境；另外框架的管理层面已经是成熟的不需要再过多去考虑）。框架的应用和流行和MVC设计理念息息相关，而MVC本身不是为了简化什么，而是为了规范什么。如果对MVC都不认可那就更谈不上对框架的理解了。楼主说得没错，有很多方法都比使用框架要灵活方便简捷很多，但这样的结果是你放弃了高级系统设计理念，回到了MVC之前的老思想里。在MVC之前的日子里，系统的维护、扩展、安全以及稳定都是随时可以威胁系统生命的大问题；而在开发过程中，分层的设计理念大大提高了开发的效率和开发者的面向性，并且规避了不少危险和bug。MVC和框架的出现是程序开发领域的一个进步。尽管现在还没有一个完美的框架，但框架的出现的确使编程的思想上了一个台阶，这也是大家为之奋斗和需要学习的。这样的好处是：
----1.大家想用什么开发工具没有限制（现在我们组有用Netbean也有用Eclipse的还有用DW之类的）；
在大型工程里，这并不是一件好事。 ----2.分工明确，成员要求学习掌握的东西最少，相互不冲突；
没有对系统整体的认识是不可能做出好产品的，不要求完全懂，但知道局部流程，整体原理是开发大型软件的每个开发者都必须要做到的----3.以后的维护、二次开发对技术人员的要求也最少，可大大降低人力成本；
没有规范的程序，后期维护难比登天。框架一大优势就是提高二次开发人员的效率和维护的简易性. 对技术人员的要求少不见得是什么好的地方，MVC是一个先进的开发理念，没有这个理念的二次开发人员，我想应该挺初级的吧，最起码这样的人员效率上一定有问题----4.学习了解系统结构最简单，不需要看配置文件等，清晰明了，培训成本低；
不看配置文件就简单了？如果没有规范，工程稍微大一点就让外人很难看懂。----5.界面可以做的很漂亮，表现形式不会千篇一律
不知道界面和框架有什么关系，使用框架也不是必须要用struts啊！总结一下。我认为楼主对框架理解可能有些偏激，可能认为提及框架就是SSH，其实这只是一种比较流行的组合而已，但你可以单用其中任何一个，这也是框架的使用（个人认为Spring是最有用的）啊！使用框架不过是对MVC一个规范的体现，通过使用框架，你的工程自然而然就分离各层，达到了高效先进的设计理念。一点愚见，说错了请指正。
楼上我并没有进入误区呀！而我用的方式，也是MVC呀HTML做为V
数据一层的JavaBean做为M
接口服务一层的JavaBean做为C不是么---1. 在大型工程里，这并不是一件好事。
因为我用的这种MVC架构真正把各层都分开了，所有连接通讯都是访问的统一接口，所以没必要要求相应人员用什么工具，只要完成功能就行了，做HTML和JS页面的人没必要要求统一用NetBean这类开发工具，人家用Dreamweaver更好用，写JavaBean的只要完成相应接口，也没必要规定人家用JCreater还是记事本之类，他用着方便就行了，还有我这种架构下还真没有做过大型项目，不知道效果怎么样，以后再说---2.没有对系统整体的认识是不可能做出好产品的，不要求完全懂，但知道局部流程，整体原理是开发大型软件的每个开发者都必须要做到的好像现在工厂化的开发，是不需要了解这么多的，只需要把交给你的功能模块按设计要求完成就可以了---3.没有规范的程序，后期维护难比登天。框架一大优势就是提高二次开发人员的效率和维护的简易性. 我这种架构是没有规范的么？？我可不是JSP时把代码都写的页面里，分层，接口，对像是必要的，我赶说只要会写JavaBean的一个学生就可以理解我的架构，可以按设计要求完成Bean的功能，而不用先要学会了SSH这三个框架，然后再理解我的业务后，再开始二次开发和维护---4.不看配置文件就简单了？如果没有规范，工程稍微大一点就让外人很难看懂。按我这种架构写系统，工程再大，代码再多，也是相应接口--》抛数据--》接收数据，这就是最核心的功能，没有什么复杂的，总比要看几百个XML文件要强多了吧---5.不知道界面和框架有什么关系，使用框架也不是必须要用struts啊！
没有关系，不过只要用Tag后好多界面表现形式都一个样，这点总是这样吧
我也总结一下，我也在使用框架，jQuery/DWR/JSF/struts/Hibernate都用过，但是我还是喜欢那些超轻巧型的框架，那种学习、使用简单，提高开发效率的框架，比如jQuery感觉就很好，不用怎么深学，基本一看就明白了，马上就可以用在HTML页面上，通过JSON数据进行交换，后台只要JavaBean和servlet足够了，层次很清楚，代码也很直接，新人上手很容易就理解了，要求也不高，反观SSH这类框架，你要是不学上个十天八天的，根本就上不了手，如果没有IDE帮助，光那几百个XML文件都能把你看晕了，如果在客户那里现厂改点东西，你不会需要安装一个IDE吧，我这种架构下，只要用记事本改改，重新编译一下Bean，重新把包就OK了，这点功能有JDK就足够了，简单方便。当然SSH这类框架不是不好，但是现在中国这种风气我感觉不好，不要把这种框架当神一样供着，新技术总会出现，SSH这类框架也会淘汰，只有Web程序的本质不会变，适当应用框架解决必要问题方是上上只选
楼主言必“几百个XML文件”，但我感觉楼主似乎还没有经历过大型的工程。如果真的有几百个XML来配置的工程，我想按照楼主自己想法来搭建出来的程序不知道会是什么样子。即便框架里使用了几百个XML文件，关键的就是那么2-3个，其余的基本是同样格式和同压根用途，可以忽略，真正需要的时候再细看。把话先放这吧，等楼主遇到大型课题时想必会有一个更清楚的认识。SSH并非适用任何情况的工具，也不必当神来供着，但我认为S，S，还有H，比楼主自己的方法好。楼主开帖的时候让大家拍砖，那我就不客气轻拍以块，楼主的方法是一个倒退，对于楼上的几个问题的回答，让我感觉楼主对框架的认识有些问题，针对以上各点：1. 开发JS的和HTML的用不同的IDE能体现出什么优势？？这两个属同类产品，这也要分配到不同开发者的手中，我除了觉得这个工程不是超乎想象的大就是人力资源严重浪费。在大型工程中，小组开发成员最好是使用同样的IDE，因为不同的IDE配置有差别，这些差别可能导致一个人的代码无法在另一个人的环境下运行。使用相同IDE是为了把这种不必要的麻烦降到最低。当你遇到一个光配置开发环境就需要大半天功夫的工程时，你就会痛恨那些特立独行使用不同IDE的人了。2. 程序开发不同于工厂生产。工厂生产是无需用脑的简单重复，而且各项指标有硬性规定，只要严格遵守规定就能生产出合格产品。软件开发不同，每一个步骤都是大脑思考的结果，没有标准可循，对系统理解得多透彻一分，就可能提高一分质量。还是那句话，一个HelloWorld般的程序当然不需要你去了解全局，但是在大型开发里，如果眼光过于局限，很难开发出高质量的产品。3. “....我这种架构是没有规范的么....”。我认为您的那个不叫“规范”，顶多叫“规定”。有可能像你所说，一个学生都能理解你的架构，但当他真正要开始修改，添加或者维护什么的时候，刚出校门就疯了你可要负责啊！4. 刚才我说过了，几百个配置文件的工程在你的结构里会成什么样子还是个未知数。况且你并不需要每次都去读几百个配置文件，需要看哪个才看哪个。5. 没什么可说的对于你的总结，我似乎能看到些问题。JQuery是一个Javascript库，和JAVA框架没有可比性啊！随后楼主推崇javabean+servlet，这是十年前的编程模式了，看来持久层楼主用JDBC？接着楼主又提及了几百个配置文件，说实话，我真的没有见过几百个配置文件的时候，SSH里主要的也就是那么几个啊，如果要说几百个，那应该是几百个表格所产生的xxxxxx.hbm.xml？然后楼主又说在客户那里实时修改的难题，如果是我，我必然不会在客户那里修改东西，一个大型工程，稍有不慎就能造成整个系统崩溃。况且网络应用程序，在家改完了上传升级就行了，在客户那又着急又紧张还没有测试时间，改个什么劲？？？？哦，对了，如果你不带自己的电脑，服务器上的程序都是编译好了的（除了配置文件们），怎么修改？？？？如果你带自己电脑到客户那的话，还说什么安不安装IDE的事？难道平时在自己电脑上就是notepad操作？所以最后我感觉，楼主可能是从网页开发转行的。没有任何恶意，如果有太过分的用词和语气，请楼主包涵则个，就事论事而已。
ssh有他的发挥舞台，但不是所有地方都用得上ssh。
对ssh没有在深的研究.(至少源码还没有去看过.[看过部份])不过.里面的设计思想,真的很有用.
其实，当然是每个人用的多了就觉得好，但是也不一定，ssh框架的优点也有很多，比如分工明确，简单（掌握之后），需要的操作比较少，但就是配置文件比较繁琐，不如简单的jsp简单，但是很多是机器处理的，我们只需给它一个配置就可以了
我觉得spring的思想很好，最喜欢spring
只能证明你还没体验到业务服务决定模块的阶段。SSH框架不是标准，很多公司都有自己的框架。自己企业的开发规范制定是很难的。即是html(yui-ext)+json+DWR+JavaBean写一套也至少一年半载。
SSH是现在的主流，可以说是必备之技，否则在中国这样的国度里混不开，但是并不是所有项目都要以ssh来做，要结合实际。
ssh很常用，别人都用它肯定是有它的优点。如果能自己写出更好，性能更高的代码。就无所谓了
用ssh有利于后期维护啊分层明了
关键不是ssh有多好，只是如果你连ssh这样的架构都不能理解掌握，那么也就不要谈什么进一步的深入开发，可以基本判断还属于小初层次，就是一个死扣代码，什么脑筋都不动的初级程序员。BTY，ssh集中了java中优秀的设计和实践，是经过事实证明的东西另外，本人仅仅在一个小项目用过这ssh，其他都是自定义框架+JSON+IBATIS，但是，其中的自定义框架也大量借鉴了SSH的设计，也就是一个简集，为什么要多此一举，其实就是简化了一些SHH配置和不易懂的方面，让项目开发人员可以更高效的编码。但是，思想的源泉，主要来自ssh。当然也有其他的一些框架。也就是说，理不理解ssh，是判断一个程序员是初级还是初级以上的一个标准，所以面试时候，公司很喜欢问