问一个比较傻逼的问题。。。

非Java小能手，可能立即的不对，但是你是不是在说这个？： http://stackoverflow.com/questions/871405/why-do-i-need-an-ioc-container-as-opposed-to-straightforward-di-code

- 立即
+ 理解

@raincious 太好了，谢谢

你在说IoC容器么？

IoC容器获取对象，获取对象后才能“对象的方法调用”啊，两码事儿

@tabris17 直接new，不注入

@jy04149886 用IoC就是咱们不用知道对象到底怎么生成的，有些对象是new的，但是有些对象要用build或者factory模式生成。有些对象需要依赖别的服务或组件。而使用IoC容器可以让调用者无需关心这些细节。

比如一个dbconnection对象，你直接new需要传递ip端口用户名密码，你要知道从哪里去读取这些信息，到底是配置文件还是全局变量或者是常量。而是用IoC就只要把这些信息写入配置文件就可以了

@tabris17 这个我知道，比如数据库连接对象通过注入取得是很方便的，但是一个action调用它的service对象通过依赖注入来实现，我感觉好烦琐，但是现在的java三层架构的开发都是这种模式的吧。。。。是不是对这个模式使用的有点不合适。。。

@jy04149886 你就姑且认为是一种DI的美学吧……

或者说“用new太low了”

@tabris17 好吧。。。

@jy04149886
http://coolshell.cn/articles/9949.html

注入的优势在于，你只告诉接口你想干什么，至于最后这个事情怎么干，谁来干，可以执行的时候才决定

注入方便测试

@windyboy 这机制确实很强大，不过超级大项目才体现优势吧。。。做个管理软件什么的，我看貌似没什么必要。。。

@fangzhzh 貌似现在都用注解来实现了，貌似没有xml那么强大？

何必纠结什么模式呢？怎么方便怎么来啊。

@jy04149886

看你的项目到底要规范化到什么程度。

一般来说通用的代码除非出于冗余性以及组建依赖的考虑，一般还是抽出来做成可复用的流程。使用IoC方法可以轻易地做到这一点，而且可以更加灵活的进行加载（比如你可以决定是否缓存某个对象的实例，来实现比如复用数据库连接的实例），代码量可以更少。

反过来说如果你的代码里都是直接new出来，首先是维护不方便，如果这些被new的组件有更新导致调用方式改变（比如拆分了之类），那么可能需要改的地方就太多了，不便维护。而且代码一长，维护就相对更困难。

代码总归还是给人看的。

解耦，模块化，当然可以不用，自己决定:)
设计模式的问题也争论挺久了

团队作战，写好接口，各写各的。

@invite 怎么方便怎么来？垃圾代码就是这么出来的。

注入的出发点就是为了解耦。至于为什么要解耦，怎么实现解耦的，解耦是什么意思。楼主可以顺着这个思路继续学习。

多说点，至于你现在做的东西要不要采用注入，还需要你自己学习之后结合实际情况，具体分析。很多架构、模式、框架不是说什么地方都要用。但是不用，是因为自己知道这个东西，分析之后决定不用。而不是因为自己啥也不懂，眼前怎么省事怎么来。

楼主这个问题一点都不傻逼，反而是有些回答……