persistencecontext？Spring MVC 配置文件讲解

大家好，今天我将为大家揭秘persistencecontext和Spring MVC 配置文件讲解的奥秘，希望我的分享能给你带来新的启发和知识。

对比分析Struts+Spring+Hibernate与EJB3异同,越详细越好

作为一个架构师，我对EJB是既爱且恨，对Spring又恨又爱，现在我们来也把这两大技术体系来做一个全面分析和对比，希望能给大家在进行技术选型时一个更好的参考。

1.法制 VS“民主”

EJB规范一直由国际组织JCP来制定，一经通过，即作为官方标准，且各厂商都会不遗余力的推动，所以对于企业应用来说，EJB就是法，以EJB为企业应用的基础架构暂且称为法治；Spring来自开源社区，由众多的开源软件开发者参与，逐步形成的一种流行的体系标准，它的设计以IoC(反转控制)为核心，提倡所谓的“零”侵入设计原则，这里暂且称之为民主。

支持EJB的应用服务器一般是一个大而全的产品，包括了构建企业应用需要的方方面面，如果需要额外扩展一般不容易，如果对一个应用服务器不满意的话，那么可以且也只能更换整个应用服务器了，好在由于应用服务器市场百花齐放，从免费到低端再到高端，您可以任意选择；Spring从IoC容器发展而来，通过不断集成AOP、MVC、OR/Mapping以及几乎您能想到的各项服务而提供完善的企业应用架。对于一个应用，你可以自由选择具体的技术框架的实现，SSH就是最常用一套组合，然而且不说是否每个架构师拥有正确选择的能力，无论如何，最终的选择在设计之初一旦确定，要想更换便不那么容易，你不可能轻松的将一个基于Spring+ Struts的应用轻松的移植到Spring+ WebWork，更不能轻松的将一个基于Spring+ Hibernate的应用轻松的移植到Spring+ iBatis，所以对于需要长期维护和发展的应用来说，将只能寄希望于你采用的框架都能够很好的发展，并且能在升级的同时保证向前的兼容性。

综上所述，EJB由于对于整个世界是标准的，就好像是一部国际法，一旦遵循，全球通用，你可以比较轻松的在WebSphere、WebLogic甚至 JBoss之间进行切换，所以如果选择EJB，你将在一个”法制”的环境下获得最大的民主；而Spring对于整个世界看似民主的，然而一旦整套架构确定下来，却成了专制，犹如美国式的民主，一旦被它征服，就成为它的专政统治了，想挣脱它的控制可就不那么容易了，其中的利害，大家细细品味吧。

2.轻量级组件 VS轻量级内核 VS轻量级容器

关于轻量级内核，不论属实是否，现今的应用服务器都宣称采用了微内核技术，在此基础上建立Java EE的各项服务构建成完善的应用服务器；而Spring本身就是一个基于IoC的轻量内核，然后通过集成第三方的服务器来提供完整的架构。

EJB组件曾经被认为是一个重量级的组件，而备受批评，EJB3规范的重要目标就是简化EJB的开发，提供一个容器管理的轻量级的组件方案。

但是有必要提醒一下，轻量级的组件，并不意味着提供服务的容器是轻量的，不管是EJB2还是EJB3，应用服务器因为需要管理组件的负责生命周期以及行为，并且内置提供了各项服务，容器自然是一个重量级的服务；至少现在看来，现有的Application Server提供的容器都还不足够的轻量，从个人偏好来说，我就非常喜欢JBoss 2.4这个版本，它有我需要的功能，同时又够简单，而现在，JBoss 4的启动速度已经逐渐让我对它对失去了耐心。

而对于Spring，也有同样的问题，轻量级的内核，也不意味着整个框架是轻量的，更不意味着基于Spring的整个应用架构是轻量的。对于 Spring，你需要去寻找并粘合各种服务，然后让他们能够稳定的在一起工作，如果应用对技术的需求较多，伸缩性要求也较高，你就会不断的在应用服务中加入其他服务，如：资源池、消息队列、集群等。当加入这些后，Spring的解决方案已经和Java EE Application Server解决方案一样重量级了。

追求简单、轻量，是每一个应用架构的目标，对于企业应用的构建来说，轻量级组件标准+轻量的内核+轻量级的容器，并以此构建轻量级的应用平台，才是最终需要的。如果有轻量级的容器出现，将帮助EJB3在企业应用中重新占据有利的地位。

3.可管理性与可控性

这个问题对于一次性交付的项目也许不是问题，但是对于质量要求更高、生命周期更长的产品，却是衡量平台和架构的重要因素。

基于Spring架构的应用，由于过分的自由和灵活，随着项目的进展，逐渐集成的第三方框架越来越多，很难保证集成的服务和编写的组件中有没有漏洞，甚至相互之间有严重的冲突，那么，掌控整个项目的质量成了难题，光是一页接一页的配置文件，就知道今后的维护成本也就随之增高，回想一下EJB2.0时代的ejb-jar.xml吧；而EJB因为集成的都是标准服务，而且组件模型也是固定的，加之应用服务器一般提供控制台，用来查看运行时的各项属性，并可对服务进行实时的管理，显然比Spring开发的应用可控性更好。

#p#

4.功能性对比

4.1、IoC容器，AOP能力

在IoC的能力Spring要略强一些，但是在EJB3中可以完全用Annotation方式进行注入，在开发上要简单很多，对于一些相对比较固定的注入，采用Annotation更好，而对于一些可能需要经常变动的注入，XML更加灵活，EJB3刚好提供了这样的两种解决方案。如果你已经患有XML恐惧症，那么EJB3无疑将给您以解脱。

同时，EJB3组件中，支持多种方式注入，比如依赖于名称、接口或者JNDI名，另外还支持使用@PersistenceContext注入EntityManager，@Resource注入服务器资源，如EJBContext、TimerService等，而一些Annotation已经成为JDK6的一部分，将来可能直接被JDK支持。

AOP方面，如果您需要彻底的AOP，并且在Spring中集成了AspectJ，那么EJB3自然无法比拟，但是如果您的项目以够用为原则，只需要一般方法拦截意义上的AOP，EJB3提供的各种回调方法应该可以满足您的要求了。

4.2、事务处理

EJB的看家本领，Spring也通过提供TransactionTemplate以及集成第三方事务处理器来支持JTA，都支持申明式事务，可以BMT，CMT，但无论如何，移植的器官总也没有自身长的好吧。

4.3、分布式能力

一般使用Java EE体系的公司都认为这是EJB的最大长处，但是实施并不如想象那样，一来绝大多数都是Web应用，依赖Web提供的分布式能力已经可以满足90%的需要了，二来大家基本上都是Web容器和EJB容器整体部署，EJB组件的分布部署少之又少。当然如果您需要Web层和应用层分开部署，那么Spring一定不在你的考虑范围之内了。

4.4、Cluster能力

Cluster也是EJB的传统优势，但是老师说，能够发挥EJB集群优势的地方并不多，因为即使项目中采用了EJB，一般也采用Stateless SessionBean，而使用HttpSession Cluster，既然如此，无论EJB还是Spring，大家都是平等的。当然，如果您正在构建一个大型的应用，对集群的能力要求非常高，比如需要事务级的Cluster，而且还有分布式的需求，那么估计没有多少因素会让您考虑Web Server+ Spring的架构了。

4.5、Web Services

EJB3中的Web Service和EJB组件集成得如此之好，使用起来再简单不过了，如下面实例所示，JAX-WS也将逐步成为Java Web Service事实标准；至于Spring可以实现各种基于Http的远程调用方法，其优势并不明显。

@Remote

@Local

@WebService(endpointInterface="jfox.test.ejb3.webservice.Calculator")

public class CalculatorBean implements CalculatorRemote, CalculatorLocal{

public int add(int x, int y){

return x+ y;

}

public int subtract(int x, int y){

return x- y;

}

}

4.6、集成第三方框架

如果需要集成第三方框架的时候，估计您需要Spring了，当然前提是Spring已经给出很好的集成方案；而如果采用EJB，则需要视特定的应用服务器了，推荐当类库来用，或者使用context listener来启动，是在不行，只能基于特定的应用服务器来进行集成，一般来说，应用服务器均提供了JMX集成能力。

5.总结

纵观人类历史，官方过于强势，则必然官逼民反；而民间力量过于强大，社会必将不稳定，这都是我们不愿看到的，在技术世界里也一样。对于EJB3和Spring这两种方案，Spring现在处于压倒性的优势一方，希望EJB3的出现，一来能为官方挽回一些失去的领地，二来也能继续引发更多的探讨，不再拘束于一家之言，只有百家争鸣的环境，才能让开发人员和架构人员对企业应用的构建认识得更加完善，所以最好的方式是EJB3和Spring互相促进，和谐发展。

期待一个轻量的真正以开发需求为中心的EJB3应用服务器的出现，为疲软的EJB市场注入新的活力！

jpa+project改成java+project

将JPA项目转化为Java项目的步骤包括：

1.修改项目配置文件：打开项目目录下的pom.xml或build.gradle配置文件，对依赖的JPA相关库进行注释或删除，替换为Java Web项目所需要的依赖库。

2.更改项目结构：将原本用于持久化操作的实体类或者数据访问接口保存为Java类，并修改业务逻辑部分。

3.修改持久化方式：如果原先使用的是JPA作为持久化技术，那么需要将其更改为Java Web项目所需要的数据访问技术，例如使用JDBC、MyBatis等。

4.修改代码中的JPA API方法：需要将原本的JPA相关API方法移除，替换为Java Web项目所需要的方法，例如使用Java Servlet API等。

5.对项目进行编译打包：使用Java Web项目所需要的构建工具对整个项目进行编译打包，生成可运行的Java Web应用程序。

需要注意的是，JPA和Java项目的差异较大，如果没有相关的开发经验，可能需要花费一些时间来理解和调整代码。

Spring MVC 配置文件讲解

使用@Controller定义一个控制器

使用@RequestMapping映射请求

使用@RequestParam绑定请求参数到方法参数

使用@ModelAttribute提供一个从模型到数据的链接

使用@SessionAttributes指定存储在会话中的属性

<context:annotation-config/>

他的作用是隐式地向 Spring容器注册

AutowiredAnnotationBeanPostProcessor、

CommonAnnotationBeanPostProcessor、

PersistenceAnnotationBeanPostProcessor、

RequiredAnnotationBeanPostProcessor

这 4个BeanPostProcessor。

例如：

如果想使用@ Resource、@ PostConstruct、@ PreDestroy等注解就必须声明CommonAnnotationBeanPostProcessor。

如果想使用@PersistenceContext注解，就必须声明PersistenceAnnotationBeanPostProcessor的Bean。

如果你想使用@Autowired注解，那么就必须事先在 Spring容器中声明 AutowiredAnnotationBeanPostProcessor Bean。传统声明方式如下：

<bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor"/>

如果想使用@Required的注解，就必须声明RequiredAnnotationBeanPostProcessor的Bean。同样，传统的声明方式如下：

<bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"/>

记得，使用注解一般都会配置扫描包路径选项

<context:component-scan base-package=”XX.XX”/>

<servlet>

<servlet-name>dispatcherServlet</servlet-name>

<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

<init-param>

<param-name>contextConfigLocation</param-name>

<param-value>/WEB-INF/dispatcherServlet-servlet.xml</param-value>

</init-param>

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>dispatcherServlet</servlet-name>

<url-pattern>*.do</url-pattern>

</servlet-mapping>

这个配置常常见于web.xml文件中

<load-on-startup>1</load-on-startup>是启动顺序，让这个Servlet随Servletp容器一起启动。

<url-pattern>*.do</url-pattern>会拦截*.do结尾的请求。

<servlet-name>dispatcherServlet</servlet-name>这个Servlet的名字是dispatcherServlet，可以有多个DispatcherServlet，是通过名字来区分的。每一个DispatcherServlet有自己的WebApplicationContext上下文对象。同时保存的ServletContext中和Request对象中，关于key，以后说明。

在DispatcherServlet的初始化过程中，框架会在web应用的 WEB-INF文件夹下寻找名为[dispatcherServlet]-servlet.xml的配置文件，生成文件中定义的bean。

<init-param>

<param-name>contextConfigLocation</param-name>

<param-value>/WEB-INF/dispatcherServlet-servlet.xml</param-value>

</init-param>

指明了配置文件的文件名，不使用默认配置文件名，而使用springMVC.xml配置文件。

其中<param-value>**.xml</param-value>这里可以使用多种写法

1、不写,使用默认值:/WEB-INF/<servlet-name>-servlet.xml

2、<param-value>/WEB-INF/classes/springMVC.xml</param-value>

3、<param-value>classpath*:springMVC-mvc.xml</param-value>

4、多个值用逗号分隔

springMVC-mvc.xml配置文件片段讲解

<context:annotation-config/>

<!--自动扫描的包名-->

<context:component-scan base-package="com.iflysse"/>

<!--默认的注解映射的支持-->

<mvc:annotation-driven/>

<!--视图解释类-->

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">

<property name="prefix" value="/WEB-INF/jsp/"/>

<property name="suffix" value=".jsp"/><!--可为空,方便实现自已的依据扩展名来选择视图解释类的逻辑-->

<property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>

</bean>

<mvc:annotation-driven/>是一种简写形式，完全可以手动配置替代这种简写形式，简写形式可以让初学都快速应用默认配置方案。<mvc:annotation-driven/>会自动注册DefaultAnnotationHandlerMapping与AnnotationMethodHandlerAdapter两个bean,是spring MVC为@Controllers分发请求所必须的。

并提供了：数据绑定支持，@NumberFormatannotation支持，@DateTimeFormat支持，@Valid支持，读写XML的支持（JAXB），读写JSON的支持（Jackson）。

后面，我们处理响应ajax请求时，就使用到了对json的支持。

后面，对action写JUnit单元测试时，要从spring IOC容器中取DefaultAnnotationHandlerMapping与AnnotationMethodHandlerAdapter两个bean，来完成测试，取的时候要知道是<mvc:annotation-driven/>这一句注册的这两个bean。

<!-- json支持-->

<bean id="mappingJacksonHttpMessageConverter"

class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter">

<property name="objectMapper" ref="commonObjectMapper"/>

<property name="supportedMediaTypes">

<list>

<value>text/html;charset=UTF-8</value>

</list>

</property>

</bean>

<!-- ObjectMapper json转换-->

<bean id="commonObjectMapper" class="cn.com.starit.util.CommonObjectMapper"/>

关于本次persistencecontext和Spring MVC 配置文件讲解的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。