大部分项目都少不了spring的身影，为什么大家对他如此青睐，而且对他的追捧丝毫没有减退之势呢?
Spring是什么：
Spring是一个轻量级的DI和AOP容器框架。
说它轻量级有一大部分缘故原由是相对与EJB的(虽然本人从没有打仗过EJB的运用)，主要的是，Spring是非侵入式的，基于spring开拓的运用一样平常不依赖于spring的类。
DI：称作依赖注入(Dependency Injection),和掌握反转一个观点，详细的讲，当一个角色须要其余一个角色帮忙的时候，在传统的程序设计中，常日有调用者来创建被调用者的实例。但是在spring中创建被调用者将不再有调用者完成，因此叫掌握反转。创建被调用工具有Spring来完成，在容器实例化工具的时候主动的将被调用者(或者说它的依赖工具)注入给调用工具，因此又叫依赖注入。
AOP：Spring对面向切面编程供应了强有力的支持，通过它让我们将业务逻辑从运用做事(如事务管理)等分离出来，实现了高内聚开拓，运用工具只关注业务逻辑，不再卖力其它系统问题(如日志、事务等)。Spring支持用户自定义切面。
面向切面编程是面向工具编程的有力补充。面向工具编程将程序分成各个层次的工具，面向切面的程序将运行过程分解成各个切面。AOP是从运行程序的角度去考虑程序的构造，提取业务处理过程的切面，OOP是静态的抽象，AOP是动态的抽象，是对运用实行过程的步骤进行抽象，从而得到步骤之间的逻辑划分。
容器：Spring是个容器，由于它包含并且管理运用工具的生命周期和配置。如工具的创建、销毁、回调等。
框架：Spring作为一个框架，供应了一些根本功能，(如事务管理，持久层集成等)，使开拓职员更专注于开拓运用逻辑。
看完了Spring是什么，再来看看Spring有哪些优点
1.利用Spring的IOC容器，将工具之间的依赖关系交给Spring，降落组件之间的耦合性，让我们更专注于运用逻辑
2.可以供应浩瀚做事，事务管理，WS等。
3.AOP的很好支持，方便面向切面编程。
4.对主流的框架供应了很好的集成支持，如hibernate,Struts2,JPA等
5.Spring DI机制降落了业务工具更换的繁芜性。
6.Spring属于低侵入，代码污染极低。
7.Spring的高度可开放性，并不逼迫依赖于Spring，开拓者可以自由选择Spring部分或全部
Struts2的优点
Struts2 是一个相称强大的Java Web开源框架，是一个基于POJO的Action的MVC Web框架。它基于当年的Webwork和XWork框架，继续其优点，同时做了相称的改进。Struts2现在在Java Web开拓界的地位可以说是大红大紫，从开拓职员的角度来剖析，Struts2之以是能够如此的深入开拓职员之心，与其优秀的设计是分不开的。
1、Struts2基于MVC架构,框架构造清晰，开拓流程一览无余，开拓职员可以很好的掌控开拓的过程。
我在项目开拓过程中，一个详细的功能的开拓流程是：拿到一个详细的功能需求文档和设计好的前台界面(在开拓中我不卖力设计页面)，剖析须要从前台通报哪些参数，确定参数的变量名称，在Action中设置相应的变量，这些参数在前台如何显示，并将页面上的一些控件适当利用Struts2供应的做事器端控件来代替，编写Action对应的方法来完成业务逻辑，末了，做一些与配置文件干系的设置。当然实际的开拓比这个过程要繁芜，涉及到数据库，验证，非常等处理。但是利用Struts2进行开拓，你的关注点绝大部分是在如何实现业务逻辑上，开拓过程十分清晰明了。
2、利用OGNL进行参数通报。
OGNL供应了在Struts2里访问各种浸染域中的数据的大略办法，你可以方便的获取Request，Attribute，Application，Session，Parameters中的数据。大大简化了开拓职员在获取这些数据时的代码量。
3、强大的拦截器
Struts2 的拦截器是一个Action级别的AOP，Struts2中的许多特性都是通过拦截器来实现的，例如非常处理，文件上传，验证等。拦截器是可配置与重用的，可以将一些通用的功能如：登录验证，权限验证等置于拦截器中以完成一些Java Web项目中比较通用的功能。在我实现的的一Web项目中，便是利用Struts2的拦截器来完成了系统中的权限验证功能。
4、易于测试
Struts2的Action都是大略的POJO，这样可以方便的对Struts2的Action编写测试用例，大大方便了Java Web项目的测试。
5、易于扩展的插件机制
在Struts2添加扩展是一件愉快而轻松的事情，只须要将所须要的Jar包放到WEB-INF/lib文件夹中，在struts.xml中作一些大略的设置就可以实现扩展。常用的Struts2的扩展可以通过这个链接找到：
http://cwiki.apache.org/S2PLUGINS/home.html
6、模块化
Struts2已经把模块化作为了体系架构中的基本思想，可以通过三种方法来将运用程序模块化：
将配置信息拆分成多个文件
把自包含的运用模块创建为插件
创建新的框架特性，即将与特定运用无关的新功能组织成插件，以添加到多个运用中去。
7、全局结果与声明式非常
为运用程序添加全局的Result，和在配置文件中对非常进行处理，这样当处理过程中涌现指定非常时，可以跳转到特定页面，这一功能十分实用。
Spring MVC和Struts2的比较的优点
我们用struts2时采取的传统的配置文件的办法，并没有利用传说中的0配置。spring3 mvc可以认为已经100%零配置了(除了配置spring mvc-servlet.xml外)。
Spring MVC和Struts2的差异：
机制：spring mvc的入口是servlet，而struts2是filter(这里要指出，filter和servlet是不同的。以前认为filter是 servlet的一种分外)，这样就导致了二者的机制不同，这里就牵扯到servlet和filter的差异了。
性能：spring会轻微比struts快。spring mvc是基于方法的设计，而sturts是基于类，每次发一次要求都会实例一个action，每个action都会被注入属性，而spring基于方法，粒度更细，但要小心把握像在servlet掌握数据一样。spring3 mvc是方法级别的拦截，拦截到方法后根据参数上的表明，把request数据注入进去，在spring3 mvc中，一个方法对应一个request高下文。而struts2框架是类级别的拦截，每次来了要求就创建一个Action，然后调用setter getter方法把request中的数据注入;struts2实际上是通过setter getter方法与request打交道的;struts2中，一个Action工具对应一个request高下文。
参数通报：struts是在接管参数的时候，可以用属性来接管参数，这就解释参数是让多个方法共享的。
设计思想上：struts更加符合oop的编程思想， spring就比较谨慎，在servlet上扩展。
intercepter的实现机制：struts有以自己的interceptor机制，spring mvc用的是独立的AOP办法。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继续，以是我以为论利用上来讲，spring mvc利用更加简洁，开拓效率Spring MVC确实比struts2高。spring mvc是方法级别的拦截，一个方法对应一个request高下文，而方法同时又跟一个url对应，以是说从架构本身上spring3 mvc就随意马虎实现restful url。struts2是类级别的拦截，一个类对应一个request高下文;实现restful url要费劲，由于struts2 action的一个方法可以对应一个url;而其类属性却被所有方法共享，这也就无法用表明或其他办法标识其所属方法了。spring3 mvc的方法之间基本上独立的，独享request response数据，要求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。
其余，spring3 mvc的验证也是一个亮点，支持JSR303，处理ajax的要求更是方便，只需一个表明@ResponseBody ，然后直接返回相应文本即可。送上一段代码：
[java] view plain copy
在CODE上查看代码片派生到我的代码片
@RequestMapping(value=“/whitelists”) public String index(ModelMap map) { Account account = accountManager.getByDigitId(SecurityContextHolder.get().getDigitId()); List groupList = groupManager.findAllGroup(account.getId()); map.put(“account”, account); map.put(“groupList”, groupList); return “/group/group-index”; } // @ResponseBody ajax相应，处理Ajax要求也很方便 @RequestMapping(value=“/whitelist/{whiteListId}/del”) @ResponseBody public String delete(@PathVariable Integer whiteListId) { whiteListManager.deleteWhiteList(whiteListId); return “success”; }
struts1与struts2实质差异
1 在Action实现类方面的比拟：Struts 1哀求Action类连续一个抽象基类;Struts 1的一个详细问题是利用抽象类编程而不是接口。Struts 2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制的做事成为可能。Struts 2供应一个ActionSupport基类去实现常用的接口。纵然Action接口不是必须实现的，只有一个包含execute方法的POJO类都可以用 作Struts 2的Action。
2 线程模式方面的比拟：Struts 1 Action是单例模式并且必须是线程安全的，由于仅有Action的一个实例来处理所有的要求。单例策略限定了Struts 1 Action能做的事，并且要在开拓时非凡小心。Action资源必须是线程安全的或同步的;Struts 2 Action工具为每一个要求产生一个实例，因此没有线程安全问题。
3 Servlet依赖方面的比拟：Struts 1 Action依赖于Servlet API，由于Struts 1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts 2 Action不再依赖于Serzvlet API，从而答应Action分开Web容器运行，从而降落了测试Action的难度。 当然，如果Action须要直接访问HttpServletRequest和HttpServletResponse参数，Struts 2 Action仍旧可以访问它们。但是，大部分时候，Action都无需直接访问HttpServetRequest和 HttpServletResponse，从而给开拓者更多灵巧的选择。
4 可测性方面的比拟：测试Struts 1 Action的一个紧张问题是execute方法依赖于Servlet API，这使得Action的测试要依赖于Web容器。为了分开Web容器测试Struts 1的Action，必须借助于第三方扩展：Struts TestCase，该扩展下包含了系列的Mock工具(仿照了HttpServetRequest和HttpServletResponse工具)，从而 可以分开Web容器测试Struts 1的Action类。Struts 2 Action可以通过初始化、设置属性、调用方法来测试。
5 封装要求参数的比拟：Struts 1利用ActionForm工具封装用户的要求参数，所有的ActionForm必须连续一个基类：ActionForm。普通的JavaBean不能用 作ActionForm，因此，开拓者必须创建大量的ActionForm类封装用户要求参数。虽然Struts 1供应了动态ActionForm来简化ActionForm的开拓，但依然须要在配置文件中定义ActionForm;Struts 2直策应用Action属性来封装用户要求属性，避免了开拓者须要大量开拓ActionForm类的啰嗦，实际上，这些属性还可以是包含子属性的Rich 工具类型。如果开拓者依然怀念Struts 1 ActionForm的模式，Struts 2供应了ModelDriven模式，可以让开发者利用单独的Model工具来封装用户要求参数，但该Model工具无需连续任何Struts 2基类，是一个POJO，从而降落了代码污染。
6 表达式措辞方面的比拟：Struts 1整合了JSTL，因此可以利用JSTL表达式措辞。这种表达式措辞有基本工具图遍历，但在对凑集和索引属性的支持上则功能不强;Struts 2可以利用JSTL，但它整合了一种更强大和灵巧的表达式措辞：OGNL(Object Graph Notation Language)，因此，Struts 2下的表达式措辞功能更加强大。
7 绑定值到视图的比拟：Struts 1利用标准JSP机制把工具绑定到视图页面;Struts 2利用“ValueStack”技能，使标签库能够访问值，而不须要把工具和视图页面绑定在一起。
8 类型转换的比拟：Struts 1 ActionForm 属性常日都是String类型。Struts 1利用Commons-Beanutils进行类型转换，每个类一个转换器，转换器是不可配置的;Struts 2利用OGNL进行类型转换，支持基本数据类型和常用工具之间的转换。
9 数据校验的比拟：Struts 1支持在ActionForm重写validate方法中手动校验，或者通过整合Commons alidator框架来完成数据校验。Struts 2支持通过重写validate方法进行校验，也支持整合XWork校验框架进行校验。
10 Action实行掌握的比拟：Struts 1支持每一个模块对应一个要求处理(即生命周期的观点)，但是模块中的所有Action必须共享相同的生命周期。Struts 2支持通过拦截器堆栈(Interceptor Stacks)为每一个Action创建不同的生命周期。开拓者可以根据须要创建相应堆栈，从而和不同的Action一起利用。
Hibernate优点
(1) 工具/关系数据库映射(ORM)
它利用时只须要操纵工具，使开拓更工具化，抛弃了数据库中央的思想，完备的面向工具思想
(2) 透明持久化(persistent)
带有持久化状态的、具有业务功能的单线程工具，此工具生存期很短。这些工具可能是普通的JavaBeans/POJO，这个工具没有实现第三方框架 或者接口，唯一分外的是他们正与(仅仅一个)Session干系联。一旦这个Session被关闭，这些工具就会分开持久化状态，这样就可被运用程序的任 何层自由利用。(例如，用作跟表示层打交道的数据传输工具。)
(3) 事务Transaction(org.hibernate.Transaction)
运用程序用来指定原子操作单元范围的工具，它是单线程的，生命周期很短。它通过抽象将运用从底层详细的JDBC、JTA以及CORBA事务隔离 开。某些情形下，一个Session之内可能包含多个Transaction工具。只管是否利用该工具是可选的，但无论是利用底层的API还是利用 Transaction工具，事务边界的开启与关闭是必不可少的。
(4) 它没有侵入性，即所谓的轻量级框架
(5) 移植性会很好
(6) 缓存机制，供应一级缓存和二级缓存
(7) 简洁的HQL编程
Hibernate缺陷
(1) Hibernate在批量数据处理时有弱势
(2) 针对单一工具大略的增删查改，适宜于Hibernate,而对付批量的修正，删除，不适宜用Hibernate,这也是OR框架的弱点;要利用数据库的特定优化机制的时候，不适宜用Hibernate
Hibernate和iBATIS 优缺陷比较
(把稳:iBATIS 是MyBATIS的前生，也便是1.0版本)
Hibernate的特点：
Hibernate功能强大，数据库无关性好，O/R映射能力强， Hibernate对数据库构造供应了较为完全的封装，Hibernate的O/R Mapping实现了POJO 和数据库表之间的映射，以及SQL 的自动天生和实行。程序员每每只需定义好了POJO 到数据库表的映射关系，即可通过Hibernate 供应的方法完成持久层操作。程序员乃至不须要对SQL 的闇练节制， Hibernate/OJB 会根据制订的存储逻辑，自动天生对应的SQL 并调用JDBC 接口加以实行。Hibernate的缺陷便是学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和工具模型之间如何权衡取得平衡，以及若何用 好Hibernate方面须要你的履历和能力都很强才行，但是Hibernate现在已经是主流O/R Mapping框架，从文档的丰富性，产品的完善性，版本的开拓速率都要强于iBATIS。
iBATIS的特点：
iBATIS入门大略， 即学即用，供应了数据库查询的自动工具绑定功能，而且延续了很好的SQL利用履历，对付没有那么高的工具模型哀求的项目来说，相称完美。iBATIS的缺 点便是框架还是比较简陋，功能尚有缺失落，虽然简化了数据绑定代码，但是全体底层数据库查询实际还是要自己写的，事情量也比较大，而且不太随意马虎适应快速数据 库修正。当系统属于二次开拓,无法对数据库构造做到掌握和修正,那iBATIS的灵巧性将比Hibernate更适宜。系统数据处理量巨大，性能哀求极为 苛刻，这每每意味着我们必须通过经由高度优化的SQL语句(或存储过程)才能达到系统性能设计指标。在这种情形下iBATIS会有更好的可控性和表现。
对付实际的开拓进行的比较：
1. iBATIS须要手写sql语句，也可以天生一部分，Hibernate则基本上可以自动天生，偶尔会写一些Hql。同样的需求,iBATIS的事情量比 Hibernate要大很多。类似的，如果涉及到数据库字段的修正，Hibernate修正的地方很少，而iBATIS要把那些sql mapping的地方逐一修正。
2. iBatis 可以进行细粒度的优化
比 如说我有一个表，这个表有几个或者几十个字段，我须要更新个中的一个字段，iBatis 很大略，实行一个sql UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用 Hibernate 的话就比较麻烦了,缺省的情形下 hibernate 会更新所有字段。 当然我记得 hibernate 有一个选项可以掌握只保存修正过的字段，但是我不太确定这个功能的负面效果。
例 如：我须要列出一个表的部分内容，用 iBatis 的时候，这里面的好处是可以少从数据库读很多数据，节省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE …一样平常情形下Hibernate 会把所有的字段都选出来。比 如说有一个上面表有8个字段，个中有一两个比较大的字段，varchar(255)/text。上面的场景中我为什么要把他们也选出来呢?用 hibernate 的话，你又不能把这两个不须要的字段设置为lazy load，由于还有很多地方须要一次把全体 domain object 加载出来。这个时候就能显现出ibatis 的好处了。如果我须要更新一条记录(一个工具)，如果利用 hibernate，须要现把工具 select 出来，然后再做 update。这对数据库来说便是两条sql。而iBatis只须要一条update的sql就可以了。减少一次与数据库的交互，对付性能的提升是非常重 要。
3. 开拓方面：
开拓效率上，我以为两者该当差不多。可掩护性方面，我 以为 iBatis 更好一些。由于 iBatis 的 sql 都保存到单独的文件中。而 Hibernate 在有些情形下可能会在 java 代码中保sql/hql。相对Hibernate“O/R”而言，iBATIS 是一种“Sql Mapping”的ORM实现。(iBatis 是将sql写在配置文件中的，而hibernate是自己天生的) 而iBATIS 的着力点，则在于POJO 与SQL之间的映射关系。也便是说，iBATIS并不会为程序员在运行期自动天生SQL 实行。详细的SQL 须要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。利用iBATIS 供应的ORM机制，对业务逻辑实现职员而言，面对的是纯粹的Java工具，这一层与通过Hibernate 实现ORM 而言基本同等，而对付详细的数据操作，Hibernate会自动天生SQL 语句，而iBATIS 则哀求开拓者编写详细的SQL 语句。相对Hibernate而言，iBATIS 以SQL开拓的事情量和数据库移植性上的让步，为系统设计供应了更大的自由空间。
4. 运行效率
在不考虑 cache 的情形下，iBatis 该当会比hibernate 快一些或者很多。
Spring 框架的优缺陷
Spring的上风不言而喻：
1. 供应了一种管理工具的方法，可以把中间层工具有效地组织起来。一个完美的框架“黏合剂”。
2. 采取了分层构造，可以增量引入到项目中。
3. 有利于面向接口编程习气的养成。
4. 目的之一是为了写出易于测试的代码。
5. 非侵入性，运用程序对Spring API的依赖可以减至最小限度。
6. 同等的数据访问介面。
6. 一个轻量级的架构办理方案
缺陷也显而易见
1. 中断了运用程序的逻辑，使代码变得不完全，不直不雅观。此时单从Source无法完备把握运用的所有行为。
2. 将原来该当代码化的逻辑配置化，增加了出错的机会以及额外的包袱。
3. 光阴倒退，失落去了IDE的支持。在目前IDE功能日益强大的时期，以往代码重构等让人头痛的举动越来越随意马虎。而且IDE还供应了诸多强大的赞助功能，使得 编程的门槛降落很多。常日来说，掩护代码要比掩护配置文件，或者配置文件+代码的稠浊体要随意马虎的多。
4. 调试阶段不直不雅观，后期的bug对应阶段，不随意马虎判断问题所在。
经典架构S(Struts)SH的优缺陷
Struts、Spring、Hibernate能盛行这么多年耐久不衰，自然有它的道理。J2EE最先涌现的时候，我们一样平常是采取 JSP+Servlet+JavaBean+EJB的架构，尤其是1998年～2000年这段韶光，互联网的泡沫从兴起到分裂，其波澜壮阔程度，丝毫不亚 于2008年开始的这次经济危急，在那个年代，是否节制EJB开拓技能将直接决定你的薪水能否翻一倍或者几倍。不过，Spring的作者Rod Johnson在2002年根据多年履历撰写了《Expert o-ne-on-One J2EE Design and Development》，其后又揭橥了著名的《Expert o-ne-on-one J2EE Development without EJB》一书，则彻底地改变了传统的J2EE一统天下的开拓架构，基于Struts+Hibernate+Spring的J2EE架构也逐渐得到人们的认 可，乃至在大型的项目架构中也逐渐开始运用。下面我们分别说说Spring、Struts和Hibernate的优缺陷。
Spring 是一个开源框架，是为理解决企业运用程序开拓繁芜性而创建的。框架的紧张上风之一便是其分层架构，使得每个层之间和类与类之间的关系，由原来的强绑定与强 耦合转变为不绑定和松耦合，直接面向接口编程，把设计与实现相分离的原则发挥到极致，对付单元测试也产生了很深远的影响。在Spring涌现之前，如果某 个模块没有完成，做单独模块的单元测试还是很困难的。Spring同时也是 J2EE 运用程序开拓的集成框架，由于J2EE是讲究分层理念的，Spring使得J2EE每个层之间的模块职能更加清晰。
不过，对付大型项目的开拓，Spring使得原来难以掩护的类与类之间的强耦合关系，转变为更加难以掩护的XML文件配置，这个事情量也是非常巨大 的，而且更随意马虎出错。而且，随着每个运用 模块的升级，这些模块之间的版本，也不会是同步更新的，对付同一个公共组件，有的模块用的可能是1.0版本，而另 外一个功能模块用的可能是2.0版本，恐怖的是1.0版本和2.0版本之间，可能还不兼容，Spring对付这些需求，就无能为力了。以是，有人说 Spring不适宜大型项目开拓，也是有一定道理的。最近Spring也加入了OSGI标准的实现，也是为理解决不同版本之间同时存在的这些问题。不过， 随着Spring加入的功能越来越多，Spring也就失落去了轻量开源框架的特点，变得越来越笨重。
虽然Spring现在也支持了所谓的免配置，可以通过@Autowired标签自行绑定，还可以通过 设置自动绑定加载所有的Hibernate工具，但是如果这些上百个或者数十个中的任何一个Entity工具加载失落败，则全体Spring做事就启动不起 来了，这与难于支配的EJB有啥差异呢?而且，令人可笑的是，由于利用了@Autowired标签，相称一部分开拓职员不再面向接口编程了，对付 Class A的实例，美其名曰由Spring自行绑定，接口也好，实际实现类也好，就在Spring配置一下就可以了。而Spring最核心的便是面向接口编程和 IOC，没有了面向接口编程，用一个 A a=new A() 来实例化一个Class，有什么不可以呢?少写了一行代码，引入了一个重量级的Spring，究竟为啥利用Spring呢?
对付Hibernate的盛行，则是由于开拓职员和客户，对付Entity EJB(实体EJB)臃肿的身材及支配的困难，是在极度失落望感情下造成的。既然是轻量级办理方案，那么分布式就不是可选项，没有分布式，那么EJB就无用 武之地了。话又说回来了，Rod Johnson前些年就由于强调绝大部分企业运用是不须要分布式的，从而推出了自己轻量级的Spring办理方案。但是最近一年，随着云打算架构的兴起， 架构是否支持分布式，又是必选项了。技能架构的选型，就跟法国巴黎盛行时装一样，今年盛行短袖，明年盛行下摆，真是范例的十年河东，十年河西。以是，像 SOA、云打算、SaaS、物联网这些大名词，不仅会给客户带来很大的困惑，同样也会给程序员、系统剖析师、系统架构师、技能总监带来困惑。从肯定到否 定，再到自我否定，真是符合大自然螺旋式上升的发展规律。
而对付Struts，它一经推出，险些打败了当时的所有竞争对手。Struts的伟大之处，在于它对网页数据的动态绑定。虽然数据绑定不是一个新名 词，微软在1991年推出Visual Basic1.0的时候，就创造性地发明了让VB程序员又爱又恨的数据绑定，但是对付Web 编程，Struts也还是把数据绑定首次运用到了Web编程上。它能够让人们用Set和Get的形式取得网页数据，而不是单一的黑盒式的 request.getParameter()，从而使得网页数据取值进入面向工具(OO)化时期。
Struts、Hibernate以及Spring本身都是制作精良的框架，但是对付自己产品和项目的运用，一经整合在一起，却不一定很适用。比如 说，对付数据库干系的MIS(管理信息系统)系统中，增加、修正、删除、查询功能是最基本、最常见、必不可少的。对付这些最基本的功能，不同的架构师，则 会做出不同的选择。有的架构师，选择了自动天生的理念，做一个代码自动天生器，设计好数据库表构造，单击一个脚本，或者用Eclipse插件的形式，做个 图形化天生界面，自动天生SSH框架，完成数据库的增加、修正、删除、查询操作。这么做的好处是数据库修正了，代码自动生造诣可以了，使得程序员不用再维 护这些无聊的代码。不过毛病也是致命的，一是随着Struts、Hibernate、Spring的升级，这个工具也不得不随着升级，而做这个工具的程序 员，可能早就离开公司了，后续版本无法掩护;二是如果有的业务逻辑跟这些天生的代码有交叉，数据库变更后，代码也无法再次天生了。三是公司的系统架构，则 被严重限定在SSH架构根本上，再也无法改变。有人会问：纵然限定在这三种架构上，有何不好吗?假设有客户问，你的框架支持云打算吗?你总不能说”由于 Struts、Hibernate、Spring 不支持云打算架构，以是我也不支持”以此取得客户包涵吧。因此，依赖于第三方架构的产品体系架构，随着韶光的推移，受到的限定会越来越大。
来源：http://developer.51cto.com/art/201908/601795.htm
