spring注解的疑惑

  
spring目的是解耦合，使用配置文件方式，一旦出现要修改的地方可以轻松的修改，甚至不用改java文件，不用重新编译等。
1. 如果使用注解方式，比如：@Autowired，那么如果修改起来，还是要修改源文件，重新编译。
2. 对于一些简单的接口实现等，感觉使用自动注入和new区别不大，使用注解和new效果差不多，修改起来都很费事，比如把dao注入到service：

@Autowired
@Qualifier("xxDao")
IXXDao xxDao;
和
IXXDao xxDao = new XXDaoImpl();
     感觉要换个实现类，都要修改源文件，都要修改这里，注解也就是修改量小一些，这样的话注解给人的感觉是解耦合了，但操作起来感觉也不是很简便。

3. 使用注解，开发起来很方便，的确比配置文件快，但是维护感觉很郁闷啊，经常修改别人代码，总要ctrl+H搜索自动注入的类在哪。
          所以感觉注解也不是特别牛 b啊，为什么很多人都提倡使用注解，到底注解好在哪里呢？
  前几天在其他地方问了个spring配置文件的问题，有人嘲笑我说，你都用spring2.5了，怎么还写配置文件，用注解啊，楼主什么年代的人了，md，难道新东西就一定好吗？
开发很久了，一直用配置文件，最近改用注解了，对于注解有些小疑惑，希望大家讨论讨论，解惑解惑。

1.如果使用注解，则Service 或Control都不必使用new关键字。不需要像spring aop那也set/get
2.注解使用起来很方便，在一个类上面引用注解：@Control，@Component,@Scope(value = "singleton")
@Transactional等，这些还是很神奇的。
3.创建一个类，源注释声明什么样，在开发中就扮演者什么角色。（MVC）

萝卜白菜,各有所爱,

1.如果结构设计的好，只是面向接口的编程，大部分情况不需要改源文件的。只有一小部分特殊情况才会修改。至少我用到现在都没改过。

2.如果你觉得注入和new没有区别，那是你对spring理解的问题。比如单例，比如范围域，比如你想new一个类，但是这个类在new的时候又需要别的属性做参数注入，等很多情况的发生，不是一句new就可以解决的。

3.你修改别人的配置文件难道就不用搜索bean的id了吗？除非那个配置文件很小，既然很小，在类里面也很容易找。而且一般的公司会有规范，比如哪些变量会写在类的前面，比如在dao里面把service的注入都放到一起声明。类似这些很多。

注解和xml的区别是有很多，但是不是你说的这些。而且每个人用起来也不一样，不能统一的说哪个好哪个不好。

公司一般都会有规范，起码项目经理或者架构师要确立规范。这样才能让整个团队写出的代码都能互相看懂。

@Inject
XXDao xxDaoImpl;

我一般都是这么注释。XXDao是接口名字，XxDaoImpl是实现类的名字。
很少去写@Qualifier("xxDao")这样子的。
这就是规范的好处。
我们也不会在@Server后面加名字，都是用类的名字。
当然每个地方的风格不一样而已。

有一种原则叫：契约优先！如果没有好好的规范，那劝你还是不要用annotation了。

创建一个类，源注释声明什么样，在开发中就扮演者什么角色。（MVC）


这句话不错。。

我觉得楼主说的第一点是对的
如果用了注解，确实不方便了
我们现在开发大概是这样一种情况
产品研发团队负责一个大产品的研发，然后发布编译后的版本给个省进行部署与二次开发，但并不提供源代码；
比如定义了一个某业务规则的接口IService，然后给出一个实现规则ServiceA
这个ServiceA通过Spring注入到了ActionA，ActionB，ActionC3处
现在因为省端有不同需求，ActionC处的业务规则要做修改，ActionA和ActionB不变
那对于我们二次开发来说，只要重新实现接口IService，比较叫ServiceB，然后修改配置文件，注入给ActionC即可。
如果是使用注解的方式，二次开发根本没有ActionC的代码，也就无法修改ActionC的注解

所以我觉得还是使用配置文件的方式更加灵活

IcedCoffee 写道
1.如果结构设计的好，只是面向接口的编程，大部分情况不需要改源文件的。只有一小部分特殊情况才会修改。至少我用到现在都没改过。

2.如果你觉得注入和new没有区别，那是你对spring理解的问题。比如单例，比如范围域，比如你想new一个类，但是这个类在new的时候又需要别的属性做参数注入，等很多情况的发生，不是一句new就可以解决的。

3.你修改别人的配置文件难道就不用搜索bean的id了吗？除非那个配置文件很小，既然很小，在类里面也很容易找。而且一般的公司会有规范，比如哪些变量会写在类的前面，比如在dao里面把service的注入都放到一起声明。类似这些很多。

注解和xml的区别是有很多，但是不是你说的这些。而且每个人用起来也不一样，不能统一的说哪个好哪个不好。


我没说注解不好，只是想知道他优越到什么地方，什么程度。

1. 注解方式和new的方式的确有很大不同，根本上来看完全是两个方式，我也明白，但是没看到注解比xml优越到哪？你都说不用修改源文件，那我new也是可以的。

2. 用new的方式实现单例，范围域也是可以的，注入别的属性参数也没问题，一句new完全可以解决，解决不了说明你设计模式没用好，这里感觉倒是注释有时候能方便一些，不用手写单例等等，不过不知道哪里对spring理解出问题了。

3. 修改别人配置确实可以需要用搜索，但是xml可以不用修改源码，在客户现场就可以改（虽然遇到过，但是不多，大部分时候还要改源码）。

你说的规范倒是事实，用什么方式看公司规定，不过感觉公司规定有时候也是跟风，什么火用什么，不一定什么好用什么，不过不管什么原因，规范就要遵守，不管好坏（就像一个同事说的，action，service，dao都用接口，感觉小项目麻烦，大项目还可以，开发好几年了也从来没有遇到过什么情况让他发出“啊！幸好这里用了接口”的感慨！）。

说实话，我自己也是更喜欢注解多一些，开发起来快啊，即使用配置文件，要修改时候还是麻烦，注解也麻烦，没太大区别，不过就是困惑没感觉到注解的更大好处才发问的，不过对于我们公司，快速完成感觉比别的都重要，一个月的工作非让10天完成，这样的项目面前，什么代码复查，什么重构，什么联调率，什么bug率，抓的再严，感觉代码，项目，产品的质量也都很难上去。

麻烦不麻烦是一个思想问题. 不管用啥技术, 用的好就能不麻烦, 或者尽量减少麻烦, 用的不好啥技术也白扯. 框架只是从某一方面提出了一个有用的思想, 实际用的时候还要多思考才行. 经验积累起来就不麻烦了.