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

[jy04149886]

请问，在三层架构当中，上一层调用下一层的服务，使用注入模式比使用对象的方法调用，优势在哪呢？？

[raincious]

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

[raincious]

- 立即
+ 理解

[jy04149886]

@raincious 太好了，谢谢

[tabris17]

你在说IoC容器么？

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

[jy04149886]

@tabris17 直接new，不注入

[tabris17]

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

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

[jy04149886]

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

[tabris17]

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

[tabris17]

或者说“用new太low了”

[jy04149886]

@tabris17 好吧。。。

[hcymk2]

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

[windyboy]

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

[fangzhzh]

注入方便测试

[jy04149886]

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

[jy04149886]

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

[invite]

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

[raincious]

@jy04149886

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

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

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

代码总归还是给人看的。

[caixiexin]

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

[xgfan]

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

[kedron]

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