注解的那些事

前几天去参加面试，被技术部门工作人员问道注解的使用情况（问我有什么建议），由于我使用的少，无法回答，后台才知道spring的一些问题，如下：

 

 

spring中提供的注解使开发变的简单容易，但是很多老的程序员都排斥使用注解的方式。不利于的项目的维护和变换。

注解引发的问题：

1、缺乏明确的配置导致程序的依赖注入关系不明确。

2、不利于模块化的装配。

3、给维护带来麻烦，因为你要根据源代码找到依赖关系。

4、通用性不好。如果你哪天抛开了Spring，换了别的Ioc容器，那么你的注解要一个个的删除。

***********************************************************************************************************************************************************
使用：

Spring不但支持自己定义的@Autowired注解，还支持几个由JSR-250规范定义的注解，它们分别是@Resource、@PostConstruct以及@PreDestroy。
　　@Resource的作用相当于@Autowired，只不过@Autowired按byType自动注入，而@Resource默认按 byName自动注入罢了。@Resource有两个属性是比较重要的，分是name和type，Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用 byType自动注入策略。如果既不指定name也不指定type属性，这时将通过反射机制使用byName自动注入策略。
　　@Resource装配顺序
　　1. 如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常
　　2. 如果指定了name，则从上下文中查找名称（id）匹配的bean进行装配，找不到则抛出异常
　　3. 如果指定了type，则从上下文中找到类型匹配的唯一bean进行装配，找不到或者找到多个，都会抛出异常
　　4. 如果既没有指定name，又没有指定type，则自动按照byName方式进行装配；如果没有匹配，则回退为一个原始类型进行匹配，如果匹配则自动装配；

 

hibernate中：在hibernate中大家都推荐使用注解的，因为方便，简单不用过于频繁的操作xml文件，当实体类多或者配置文件多的时候，会影响应用程序的运行性能。虽然可以通过MyEclipse反转生成，但是修改起来还是比较麻烦。

使用hibernate的注解简单，但不在使用hibernate的时候，可以不用再修改bean实体类。