• 这个是要综合考虑的问题。就拿我们在工作中的很常见的例子来说：我们会将controller、service、dao中的class交由spring管理并注入，是因为一般情况下在整个程序运行周期内，这些class只会被实例化一次，这恰好能和spring中的singleton scope相吻合。但是我们几乎很少将entity中的class交由spring管理，因为我们无法确定这些class对应的bean的生命周期。所以其实归结一句话：考虑是否将一个class交由spring管理，关键看这个class产生的bean是否符合spring提供的scope的生命周期规则。
  • 要理解为什么不用注入，首先就清楚注入的目的是什么？如果不注入，在程序中要使用某个类对象的方法，则需要去new一个对象。然后我们调用其中的方法，众所周知“程序=算法+数据”。不失一般性，在面向对象开发中，类一般有两种，一种是功能类的，主要是完成一些业务操作。一种是数据类，主要是存储数据，比如POJO。我们数据提交上来后，自己组装PO（当然也有的框架可以帮我们组装好），然后调用功能类的方法去操作这些数据，完成相应功能。如果没有使用注入的方式注入这些功能类对象，则会有空指针的问题。
  • 首先要明确service和entity的职责，对于service是功能的载体，类里有你自己写的大量方法，这些方法可复用。对于entity就只是数据的载体，类中最重要的就是各种字段了，这些字段只有在给它附值的情况才具有价值，所以不可复用。而spring为我们初始化实例（默认单例），new了一次后处处使用。回到你的问题，service中的方法无状态，可复用，所以一个程序员就一个对象就ok，但是对于实体类，他是有有状态的，你全局使用一个对象的时候，处处都在修改里面的值，并且里面的值可能会有我们上次修改之后残留下来的，这会对本次使用pojo类对象的时候造成影响，因此不合理的。所以实体类没必要注入。
  • 总结：1、实体类需要附上对应的数据才有意义；2、由spring管理并注入的类是可大量重复使用的；3、一个实体类可对应多条数据，如果实例化该类，则需要针对所有的数据实例化，这是不可能的，导致程序更加臃肿，还不如需要的时候再实例化。