为什么我们需要Spring框架？

Question

嗨,我是String的新手,正在阅读Martin Fowler撰写的文章:http://martinfowler.com/articles/injection.html

他举了一个MovieLister的例子,使用MovieFinder来寻找电影.在这个例子中,他首先提供了代码:

class MovieLister...
    private MovieFinder finder;
    public MovieLister() {
        finder = new ColonDelimitedMovieFinder("movies1.txt");
    }
}

他指出,除非你的朋友使用相同的MovieFinder实现并将电影放在同一个txt文件中,否则你不能将MovieLister给你的朋友重复使用.

是的,当然,这不是你编写组件的方式,希望有人可以重用它.相反,随着他的进步,你应该写:

class MovieLister...
    public MovieLister(MovieFinder finder) {
        this.finder = finder;       
    }
}

是的,那更好.现在你的朋友可以接管你的MovieLister并插入他自己的代码.对我来说,故事是完整的.我想念你为什么需要一个Spring框架来注入依赖项.依赖关系由朋友的代码注入MovieLister.完全停止.所有Spring设置等同于简单地实现MovieFinder接口并进行这样的调用:

MovieFinder myMovieFinder = new MyMovieFinderImpl();
MovieLister myMovieLister = new MovieLister(myMovieFinder);

简单,容易.我知道你在代码中硬编码MyMovieFinderImpl实例的创建.但是将这一点转移到XML上又有什么意义呢？程序员是否因为害怕编译代码而更喜欢更改XML而不编译以完成所有工作？对不起,我想我只是错过了这一点.几十年前,每个程序都使用依赖注入.但是在过去,依赖是由程序使用库,DOS命令行或GUI注入的.为什么现在我们需要另一种方式来注入依赖？

谢谢.

更新:

好吧,你们很多人带来了注释.在我对Spring的理解中,我可能会更习惯使用XML而不是注释.至少有一个中心位置,以更容易理解的方式列出依赖关系.有了注释,没有这样的中心位置.相反,只是魔术发生.想知道传入的参数是什么？自己去弄清楚,祝你好运.是的,我知道有智能IDE插件可以帮助导航代码.但是,为什么我们首先让一件事变得复杂,并庆祝另一件让我们的生活更轻松的事情呢？事实上,注释使代码更难以浏览和理解,因此人们为此创建IDE插件是显而易见的,我们可能首先创建不必要的东西,不是吗？

Answer 1

在"过去的日子"中,代码​​是在第一个例子中编写的.

Spring 是一个图书馆,你说它是"过去"中的一种方式.

很少在命令行或GUI上指定实现.不需要经常使用相同功能的多个实现,因为(a)系统很少像现在这样复杂,(b)它们不需要像今天那样与其他系统互操作,并且(c)深测试实施的次数要少得多.

什么是"其他东西"？春天是隔离的; 你只能带来你需要的东西.

为什么通过注释忽略配置？

目的是使用通用的,本地化的,已知的标准机制.说"几十年前每个程序都使用依赖注入"是荒谬的.几十年前,我在很多语言中编程,虽然我们做了类似的事情,但我们都有自己的实现,具有不同程度的复杂性,并且成功程度各不相同.

DI/IoC 需要 Spring 吗？不,还有许多其他DI框架证明了这一点.它是一种众所周知的,基本上标准的做法吗？是的.

Answer 2

不要将原理(DI)与一个实现(Spring)混淆.

如果您喜欢DI,但更喜欢在代码中进行布线:使用Google Guice.

如果您喜欢DI,但更喜欢在代码和可选的XML中进行连接,那么请使用CDI(来自Java EE的事物跟踪).

如果您喜欢DI并且喜欢XML(或者必须通过重新配置来改变应用程序的行为),那么就使用Spring.

如果你不喜欢DI那么......问另一个问题.

有几个相同原理的实现是很好的.