Spring+Hibernate?

我现在开始迷茫了，IoC，DI，反转控制，依赖注入，这些名词听起来充满玄妙，但事实上，IoC，不就是个Global Object Container吗？何必说的这么复杂呢？

既然只是Global Object Container，何必要搞的这么复杂呢，如此多的xml配置，还要注意bean之间的关联。
DRY，每个项目中都使用类似的配置文件，难道不是Repeat 吗？
配置文件，应该是留给最终用户配置的，一份表明对象映射关系的xml，应该是只对开发者可见的，但这个xml却要出现在发布的产品中。比如Spring 与 Hibernate 集成所配置的Dao。用户所要关心的配置仅仅是jdbc.properties，

DRY，DRY，DRY，每次都写类似的AADao，BBDao，AADaoImpl，BBDaoImpl，都写类似的xml关联refrence，不是一种Repeat吗？

对于广泛流行的Spring ＋ Hibernate 模式，作为一个已经确保可以良好运行的Dao模式，为什么不可以把 AADaoImpl，BBDaoImpl， xml都省略掉，我们只需要一个jdbc配置，以及domain model，就应该可以自动生成AADao接口，BBDao接口，同时在运行时就可以从Global Container中 get出 AADao， BBDao。
因为jdbc配置＋domain model是产生Dao的充分必要条件。我是这么认为的，但在目前的技术条件下，它却只是必要条件，远非充分条件。

别再用IoC，DI，这样高深的词汇来糊弄人了，就是一个容器而已，不应该让容器在应用中扮演主角。

我厌倦了，我真的是个懒惰的人，我超级不喜欢重复自己，但为了寻求不重复自己的方法，我现在却每天都要摸索到很晚，在纯java世界，却没有适合我要的框架，天哪，这是一个懒人所应该有的生活吗？

DRY，这些大牛们在说DRY的时候，告诉我们不要重复相同的代码，于是我们使用了大牛们的写的框架，当我们把不同大牛写的不同模块拼装到一块时，于是我们开始不断重复相同的模式，这难道不是另一种重复吗？

CRUD，多么基本的操作啊？我们至今仍要为此编码。

RoR，Grails，算了吧，他们只是更强大的php而已。

看了你上面的文字，我觉得你还是没有理解什么是IOC，以及为什么需要那些配置。
如果觉得写xml麻烦，可以写一个代码生成器搞定这些。

请指正我对IoC的理解。

这应该是一个程序员一直追求的简单高效吧！不过着好像还没有人真正到达，因为这是一个遥不可能的梦！

Ioc的关键应该是反向吧，比如以前写程序，可能是我需要什么功能，我需要主动去初始化某个类，单例也好，工厂方法也好，都是调用者主动初始化被调用者。然后对被调用者进行调用！

而Ioc则正好相反，开发者只需要设计好相应的接口，调用者跟本不关心被调用者是怎么初始化的。它只知道我需要被调用者功能的时候直接调用就可以了。

我的理解关键是主动和被动的关系。就像手术台的主刀医生一样，一伸手就有东西放到他手里，而不是他到桌子上去拿。

有了Ioc，我们设计的时候只需要关注对象之间的关系，至于怎么初始化留给容器去做吧。

粗浅理解。

我觉得你说的很好，让我更清晰的理解了IoC的思想。不过IoC容器，似乎没有让我们更方便。

但是这个起码是发现了原先编写程序的不足之处，才有了Ioc的出现，目前基于xml的配置是复杂，但是技术是不断发展的。

先是有了IoC的思想，然后有了基于xml的实现，当开发者使用起来仍然觉得过于复杂，于是可能出现一种减少xml配置或者0配置的实现方式。

但是Ioc的思想本身是进步的，不能说目前不是很方便就说Ioc怎么怎么样？它的确是控制反转，但是与以前非控制反转的区别则是本质上的。

个人愚见！

是啊，其实主要的错误在于配置复杂，而不是IoC本身。
我一直在试图减少重复编码。决定近期搞个代码生成器来，以前遇见的代码生成器都不够灵活，不能够适应新技术更新的速度。

lz有看过with EJB没。
lz对DRY的理解让人不敢苟同，模式的重复是无法避免的，而代码的重复是可以避免的。
代码生成器，想达到什么目的呢，简单、重复的代码生成根本没有意义，eclipse+ue基本就足够了。依赖注入性的配置本身数量不大，不具有大量重复性，也没有必要作生成器。