不使用依赖注入到处new的优缺点？

Question

看到新公司里的代码都是new xxService, 而不直接用依赖注入，这是为什么？

Answer 1

1. 不知道你们公司这样做是为什么，你们公司有没有使用框架，如果有使用框架的话，这样做就更不能理解了，哈哈，可能是由于某些功能要公司自己来重写吧
2. 我来说一下使用依赖注入的好处吧：1.不用自己去管理众多的对象，方便开发；2.框架对对象的管理已经优化的很好了，有可能会有性能上的优势；3.方便维护，为后期功能的增加或是更改都做好了松耦合的基础，这样是很好的。

我知道的就这些，希望能帮助到你。

Answer 2

http://stackoverflow.com/questions/1362962/when-not-to-use-ioc-and-di

Answer 3

因为项目太小吧，架构师在项目初期认为项目以后会变得复杂时肯定会使用依赖注入的方式【解耦】，提高项目可维护性，防止以后陷入到处new的困境

Answer 4

如果你修改xxService的名称，如果是使用new的，其他地方编译就会报错，你很顺利找到所有的，一并修改了。如果是依赖注入，可能在某个配置文件或者某个注解里面的会忘记修改。
好吧，其实我不是这么想的，我只是为了回答你的问题，强行想出来的一个不是优点的优点。
缺点就比较明显了，强耦合，而且容易出现把对象new的到处都是。

我想应该是有一定的历史原因的，可能是很久远的项目了，所以使用了new xxService；或者说，项目实在太小，架构这个项目的同学认为实在不需要使用框架，虽然spring已经很轻量级了。

Answer 5

大多数函数都依赖数据库连接，PHP的话完全可以在函数内用global声明$mysqli，从而拿到全局的MySQL连接对象进行CRUD操作，简单快捷。为什么一定要用依赖注入？搞那么复杂干什么。

Answer 6

这样显然就不能解耦了。

解耦就是说，实现业务逻辑的类（ejb里面叫做会话bean，spring里面叫做dao）不能直接new，而是通过组件/框架提供的方法取得。调用者这边用一个接口类型引用取得的对象。这样你如果想把业务逻辑换掉的话，把新的类编译出来再merge到原来的包中，把配置文件一改，取到的就是新的类了，只要接口不改动。

如果是ejb的话，除了不能解耦，也不能玩分布式了。