[纯议论]SSH2框架的优缺点
日期：2014-05-17 浏览次数：20719 次
[纯讨论]SSH2框架的优缺点
百度或者google【SSH2框架的优缺点】，出来的大部分是SSH2框架的整合内容，但对优缺点的讨论非常少。
分析的比较详实的是Struts2,Spring,Hibernate框架的优缺点这篇文章里面的。
其他优点不论，对一条表示疑问。
【— 需求的变更：以笔者多年的开发经验来看，很少有软件产品的需求从一开始就完全是固定的。客户对软件需求，是随着软件开发过程的深入，不断明晰起来的。因此，常常遇到软件开发到一定程度时，由于客户对软件需求发生了变化，使得软件的实现不得不随之改变。当软件实现需要改变时，是否可以尽可能多地保留软件的部分，尽可能少地改变软件的实现，从而满足客户需求的变更？答案是——采用优秀的解耦架构。这种架构就是J2EE的分层架构，在优秀的分层架构里，控制层依赖于业务逻辑层，但绝不与任何具体的业务逻辑组件耦合，只与接口耦合；同样，业务逻辑层依赖于DAO层，也不会与任何具体的DAO组件耦合，而是面向接口编程。采用这种方式的软件实现，即使软件的部分发生改变，其他部分也尽可能不要改变。】
根据小弟的开发经验来看，需求变了后，基本会导致表现层、业务逻辑层、DAO层3个层面的改动，而且改动起来工作量也不比传统的方式少。
有哪位大牛具体分析下这方面的优点？
------解决方案--------------------
如果在业务逻辑修改的情况下使用松耦合的框架，而且你的分层够明确的话是会方便很多。你最多就是替换service层的业务逻辑对象，那么在你新增一个service后不需要去修改其他相关代码，你只需要在配置中对该bean的class隐射进行修改即可。但是如果你连数据模型都需要修改那么不管你用什么那都是相当大的工作量了。那么你需要修改后台数据模型，以及hibernate的配置这个不用说，而且service层的相关代码也需要修改。但是你至少不用去管他们之间的创建和set的一些东西了。总归还是会方便一些
------解决方案--------------------
1，冗余代码多，ssh组合后的jar多达40个，其中很多jar中就只引用到了一个class，大部分功能都是在实际开发中用不到的！
2，运行效率低，就拿hibernate和jdbc作比较。
同样的数据库，同样的表，同样的连接池，5千条数据的查询，jdbc比hibernate最起码快0.1秒，有时候快0.6秒。
很多人使用hibernate是因为hibernate方便，在数据层中可节省不少代码。
其实把jdbc包装一下，根据java反射机制同样具有封装数据实体的功能，可以让代码比hibernate更精简！
3，配置文件多，ssh的配置繁琐是众所周知的，虽然也能做到壹配置，但对ssh的掌握要求很高。
4，项目启动慢，ssh组合的项目在windows平台下的服务器中启动一下，最少要15秒，有时多达30秒，
程序员要面对这漫长而又无奈的等待，如果是性子急的人，还真是一个考验。
5，适应能力弱，不能在main方法中运行spring3，会让你很多地方感到郁闷！
6，开发效率低，没有代码生成器，每个java文件都要右键单击新建，纯体力活。
------解决方案--------------------
要理解ssh的好处，不是一朝一夕的事，做了8个10个大型项目，才能有所体会。
首先代码即是设计，设计就是代码。考虑周全的设计、封装良好的框架，即是没有ssh一样不会差。
ssh最大的贡献是其思想而非发布出来的jar包。了解struts的产生背景和mvc模式，hibernate的orm思想，spring的面向对象、依赖注入、实现依赖接口而非接口实现依赖等等，这些远比代码本身重要。如何体会这些思想的重要性？很简单，不用struts，用jsp+servlet写一个web程序，稍大一点有二三十个功能的，不要helloworld，体会一下mvc的好处。写一个有二三十张表的应用程序，不用hibernate，看看难度如何。
也许你还是可以说，没有struts、hibernate我仍然可以很好地完成程序，的确，程序本身难度并不大，只要足够细心，程序最终可以完成。这就是另一层次的问题了，做为程序员的我们，应该把精力放在什么地方，一个一个地去对entity属性与数据库字段，一遍又一遍看看servlet的访问路径是否正确，页面上的username到服务器端不会误写成name等等。程序员的时间很宝贵，应该放在理解需求、完成良好的程序设计，而不是浪费在这种不需要动脑筋的比对名字的体力活上面。有了struts、hibernate，可以将程序员从这种无意义的活动中解脱出来，这非常有用。原因有1、实用框架能较少笔误这种低级错误，实用hibernate，加上myeclipse的自动化工具，能将错误降低到0。有过开发经验的人都知道，如果写代码花1个小时，通常找bug需要花半天的时间，而这些几乎有一半以上是笔误。2、提高开发速度，这个就不多说了。3、便于维护，如果数据库表添加了一个字段，改一下entity和映射文件，剩下的就交给hibernate完成吧。
以最少的时间，最小的工作量，完成高质量的、便于扩展的、易于维护的项目，这是框架的真正好处，需要站在软件工程的角度才能体会。
------解决方案--------------------
ssh2應該被拋棄了，
站在開發人員的角度:
1.能解決協同開發，單現在系統都是模塊化，協同開發的概率不多
2.代碼分層，方便維護，代碼的業務量大的時候不見得非常好維護
3.開發效率，其開發效率是多人協作和代碼生成器，如果沒有這兩項或中間一項，基本沒有效率可言
4.方便維護，系統模塊化了，維護也更加方便，框架當業務量大的時候，維護也是一個難事
5.jsp頁面沒有java代碼，前部用struts2標籤也不見得容易維護
站在架構人員的角度:
1.系統效率低下，不能通過軟件集成，不集成的話，一台服
百度或者google【SSH2框架的优缺点】，出来的大部分是SSH2框架的整合内容，但对优缺点的讨论非常少。
分析的比较详实的是Struts2,Spring,Hibernate框架的优缺点这篇文章里面的。
其他优点不论，对一条表示疑问。
【— 需求的变更：以笔者多年的开发经验来看，很少有软件产品的需求从一开始就完全是固定的。客户对软件需求，是随着软件开发过程的深入，不断明晰起来的。因此，常常遇到软件开发到一定程度时，由于客户对软件需求发生了变化，使得软件的实现不得不随之改变。当软件实现需要改变时，是否可以尽可能多地保留软件的部分，尽可能少地改变软件的实现，从而满足客户需求的变更？答案是——采用优秀的解耦架构。这种架构就是J2EE的分层架构，在优秀的分层架构里，控制层依赖于业务逻辑层，但绝不与任何具体的业务逻辑组件耦合，只与接口耦合；同样，业务逻辑层依赖于DAO层，也不会与任何具体的DAO组件耦合，而是面向接口编程。采用这种方式的软件实现，即使软件的部分发生改变，其他部分也尽可能不要改变。】
根据小弟的开发经验来看，需求变了后，基本会导致表现层、业务逻辑层、DAO层3个层面的改动，而且改动起来工作量也不比传统的方式少。
有哪位大牛具体分析下这方面的优点？
------解决方案--------------------
如果在业务逻辑修改的情况下使用松耦合的框架，而且你的分层够明确的话是会方便很多。你最多就是替换service层的业务逻辑对象，那么在你新增一个service后不需要去修改其他相关代码，你只需要在配置中对该bean的class隐射进行修改即可。但是如果你连数据模型都需要修改那么不管你用什么那都是相当大的工作量了。那么你需要修改后台数据模型，以及hibernate的配置这个不用说，而且service层的相关代码也需要修改。但是你至少不用去管他们之间的创建和set的一些东西了。总归还是会方便一些
------解决方案--------------------
1，冗余代码多，ssh组合后的jar多达40个，其中很多jar中就只引用到了一个class，大部分功能都是在实际开发中用不到的！
2，运行效率低，就拿hibernate和jdbc作比较。
同样的数据库，同样的表，同样的连接池，5千条数据的查询，jdbc比hibernate最起码快0.1秒，有时候快0.6秒。
很多人使用hibernate是因为hibernate方便，在数据层中可节省不少代码。
其实把jdbc包装一下，根据java反射机制同样具有封装数据实体的功能，可以让代码比hibernate更精简！
3，配置文件多，ssh的配置繁琐是众所周知的，虽然也能做到壹配置，但对ssh的掌握要求很高。
4，项目启动慢，ssh组合的项目在windows平台下的服务器中启动一下，最少要15秒，有时多达30秒，
程序员要面对这漫长而又无奈的等待，如果是性子急的人，还真是一个考验。
5，适应能力弱，不能在main方法中运行spring3，会让你很多地方感到郁闷！
6，开发效率低，没有代码生成器，每个java文件都要右键单击新建，纯体力活。
------解决方案--------------------
要理解ssh的好处，不是一朝一夕的事，做了8个10个大型项目，才能有所体会。
首先代码即是设计，设计就是代码。考虑周全的设计、封装良好的框架，即是没有ssh一样不会差。
ssh最大的贡献是其思想而非发布出来的jar包。了解struts的产生背景和mvc模式，hibernate的orm思想，spring的面向对象、依赖注入、实现依赖接口而非接口实现依赖等等，这些远比代码本身重要。如何体会这些思想的重要性？很简单，不用struts，用jsp+servlet写一个web程序，稍大一点有二三十个功能的，不要helloworld，体会一下mvc的好处。写一个有二三十张表的应用程序，不用hibernate，看看难度如何。
也许你还是可以说，没有struts、hibernate我仍然可以很好地完成程序，的确，程序本身难度并不大，只要足够细心，程序最终可以完成。这就是另一层次的问题了，做为程序员的我们，应该把精力放在什么地方，一个一个地去对entity属性与数据库字段，一遍又一遍看看servlet的访问路径是否正确，页面上的username到服务器端不会误写成name等等。程序员的时间很宝贵，应该放在理解需求、完成良好的程序设计，而不是浪费在这种不需要动脑筋的比对名字的体力活上面。有了struts、hibernate，可以将程序员从这种无意义的活动中解脱出来，这非常有用。原因有1、实用框架能较少笔误这种低级错误，实用hibernate，加上myeclipse的自动化工具，能将错误降低到0。有过开发经验的人都知道，如果写代码花1个小时，通常找bug需要花半天的时间，而这些几乎有一半以上是笔误。2、提高开发速度，这个就不多说了。3、便于维护，如果数据库表添加了一个字段，改一下entity和映射文件，剩下的就交给hibernate完成吧。
以最少的时间，最小的工作量，完成高质量的、便于扩展的、易于维护的项目，这是框架的真正好处，需要站在软件工程的角度才能体会。
------解决方案--------------------
ssh2應該被拋棄了，
站在開發人員的角度:
1.能解決協同開發，單現在系統都是模塊化，協同開發的概率不多
2.代碼分層，方便維護，代碼的業務量大的時候不見得非常好維護
3.開發效率，其開發效率是多人協作和代碼生成器，如果沒有這兩項或中間一項，基本沒有效率可言
4.方便維護，系統模塊化了，維護也更加方便，框架當業務量大的時候，維護也是一個難事
5.jsp頁面沒有java代碼，前部用struts2標籤也不見得容易維護
站在架構人員的角度:
1.系統效率低下，不能通過軟件集成，不集成的話，一台服
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
