求指教-采用纯粹SSH/SSH2技术之不可取

一.spring优缺点
    优点1：分层架构，使得每个层之间类和类之间的关系转变为不绑定和松耦合，直接面向接口编程，把设计和实现相分离的原则发挥到极致。
    优点2：单元测试，在spring没有出现之前，如果某个模块没有完成，做单独的单元测试还是很困难的。
    优点3：职能划分，spring是讲究分层的，使得J2EE每个层之间的模块职能更加清晰。
    缺点1：IOC容器劣势，对于大型项目而言，spring使得之前类与类之间难以维护的强耦合关系，转变为更加难以维护的xml配置文件，不仅工作量巨大，且更容易出错，错后还不容易查错。
    缺点2：版本同步更新需求，随着每个应用模块的升级，模块之间的版本，是不会同步更新的，对于一个公共组件，有的模块用是1.0，有的模块用的可能是2.0，可怕的是，两个版本有可能还不兼容，spring对于这些需求就无能为力了。（Spring加入OSGI标准的实现，就是为了解决不同版本之间存在的这些问题，随着spring功能的增加，也就失去了轻量开源框架的特点，变得越来越笨重。）
    缺点3：@Autowired免配置难部署：第一：通过@Autowired标签自行绑定，加载hbm文件，但是如果有任何一个Entity对象加载失败，整个spring就加载失败了，与难于部署的EJB没有区别。第二：使用@Autowired标签后，开发人员不再面向借口编程了，而spring的核心就碍于面向借口编程和IOC，没有了接口编程，多一句A a = new A（），多一句代码，却少引用了一个重量级的spring，有何不可？
    缺点四：分布式问题，spring轻量级架构的诞生是源于强调大部分企业是不需要分布式的，但是随着云计算的兴起，架构是否支持分布式，又成为了必选项。

二.hibernate优点和不适用于平台存储方案之处
    优点1：面向对象的方法存取数据库。
    优点2：缓存机制。
    优点3：懒加载机制。
    劣势：若为云架构，则需要支持多租户，支持每个租户定义自己的UI、数据库和业务逻辑，即理论上我们支持每个用户的数据库设计可以完全不一样，但是中间层的代码不发生任何变化，这就要求我们不能采用hibernate作为存储方案。（hibernate要求每个实体表必须对应一个实体javabean和hbm文件，通过annotation可以省掉hbm文件，但是实体javabean却不能省，因为它需要支持缓存机制，没有实体javabean，缓存机制就很难准确匹配）

三.struts优点和不适用于平台存储方案之处
优点：面向对象的方法存储网页数据，使用get和set这类面向对象的技术来存取网页信息，是struts的伟大之处。
劣势：若为云架构，则需要支持多租户，多租户意味着用户的业务逻辑和界面有可能是不一样的，试图引导客户标准化作业，试图一套软件走遍天下是不符合saas要求的，此故，纯粹的struts也是不可取的。

总结：对第三方架构的依赖，代码生成器或者插件，生成SSH架构及增删改基本操作导致的问题：第一：SSH升级，代码生成器或者插件也需要升级，而做代码生成器或者插件的人已经离职，导致后续版本无法维护。第二：如果业务逻辑和生成的代码有交叉，数据库变更后，代码也无法生成了。第三：架构被捆死在SSH上，再也无法变更（随着时间的推移，依赖于第三方产品体系架构，受到的限制会越来越大。） 

转载于:https://www.cnblogs.com/b001/archive/2012/10/15/2724013.html