第二点，各个类之间的相互引用操作少了，耦合降低了，比如我喜欢吃水果，今天吃苹果，于是我在1000个类的eat函数中书写了Fruit fruit= new Apple();结果我明天要吃橘子，原先的做法是打开1000个文件，将那句代码改成Fruit fruit = new Orange(); 累还不说，你电脑内存够么？IDE不崩溃吗？有了IOC，只需要在.xml文件中设置<bean>
随着历史的发展，由于各种局限性，旧事物总是被新事物所取代（人越来越懒）上面这种方式缺点也很明显，书写一个bean太长了！所以就出现了注解@Resource，只需在属性声明上面写上，这样一个bean，就被注入了，但是！这样和直接new区别大吗？不大！当然，也失去了那2个好处。所以对于实体类，注解用处不明显
现在，你可能回想：前者情况下配置文件好用，后者情况下注解好用，那我该选哪个？可不可以既当婊子又立牌坊？答案是可以的，就是混合使用注解和配置文件，但是！注解必须放到第二层及之后才能用，第一层必须声明文件路径：
ApplicationContext ac = new ClassPathXmlApplicationContext("beans.xml"); FruitBox fruitBox = ac.getBean("fruitBox");//此时，fruitBox跟orange，apple只是从属关系，而不是继承关系了Box内水果属性注解格式：
//这种做法其实本末倒置，因为注解就是为了解决配置文件书写问题的 @Autowired @Qualifier("fruit")//.xml中要配置一个bean,类是Orange或Apple private Fruit fruit;//照样需要一个水果父类统一接收，不写默认类名 正确做法 @Autowired private Orange fruit;所以第一层并不能享受到注解的便利。当然，举这个吃水果例子是不恰当的，因为水果实际并没有附属于任何东西，强行加一层外壳，最终增加的是内层几条注解的工作量，添加及引用外壳bean的操作量并没有减少！如果是 学生的课本 会比较合适。
也就是说对于@resource或@autowired,注解本身的便利是牺牲了灵活性的，同理，想要灵活性必须牺牲便利。所以需要特殊配置的bean用注解不合适！注解适用于new一个简单的实例，再无其他。
但是，对于controller和service，注解的好处就体现出来了，原本需要分别继承controller抽象类和service抽象类，重写各种函数，现在只需要加上@controller和@service，spring就能认出来这两种类，不再需要重写任何函数，省事的同时代码也清爽了。
ModelAndView
Model
ModelMap
Map
View
String
void
ModelAndView
@RequestMapping("/article") public ModelAndView getView() { String message = "view"; return new ModelAndView("view", "message", message);//指定返回的页面名称，也可以通过setViewName()方法指定 }