例如,如果我有一个ContainingClass和DependencyClass(及其接口):
public class ContainingClass {
IDependencyClass d;
public ContainingClass(IDependencyClass d){
this.d = d;
}
}
它们足够分离。这时,显然我们可以使用构造函数来连接它们。为什么还要在春天的背景下定义它们?
你们能谈谈使用弹簧容器管理豆子有什么好处吗?提前谢谢。
另外:如果我们使用弹簧容器太多,我认为维护容器和重构代码是相当困难的。不是吗?
答案 0 :(得分:1)
容器通常用作负责实例化所有对象的顶级实体。它解决了您最终必须解决的问题,因为某些事情必须将所有对象组合在一起并使您的应用程序生动起来。
在依赖注入框架之前,人们通过使用负责将对象连接在一起的单独的Factory类来解决这个问题。在较大的应用程序中,这导致了许多不必要的样板类,除了在一组对象上调用“new”之外什么都不做。 Spring允许您基本上从应用程序中删除该问题。
对于非常小的应用程序,您可能不会觉得必须构建应用程序,并且使用弹簧容器可能有点过分。但对于较大的应用,使用像弹簧这样的容器可以减少样板切割,并且可以更容易地将应用程序的各个部分连接在一起用于测试目的,而无需每次都将整个应用程序环境连接在一起。
此外,依赖注入容器鼓励某种编码风格,这通常会导致更可测试的系统,即注入依赖关系而不是在构造函数中新建它们。这使您可以轻松地将模拟对象替换为数据库连接等。
对于您的具体问题,答案是您的应用程序中必须存在一些其他类,它们知道如何实例化ContainingClass
,以及在哪里找到IDependencyClass
的实例。 Spring可以为你做这个,或者你必须写一个自己做的类。
答案 1 :(得分:0)
以下三点需要考虑:
首先使用Spring是否有意义?对于包含may类和包的大型Java Web应用程序 - 是(假设您考虑了任何可能的替代方案)。如果它只是几行Java App - 可能,没有。
一致性。如果项目的其余部分是Spring到核心并在XML中配置为bean,那么您可能会坚持这一点。怎么做其他事情?你是从头开始使用Spring MVC吗?然后坚持使用该模式,您可以在Spring文档中看到大量示例。
你的两个班级是如何脱钩的。例如,如果您的ContainingClass
是服务层上的服务而您的IDependencyClass
是数据访问层上的DAO,那么我很可能会单独配置它们并让Spring进行注入。特别是,当我计划在另一个上下文中使用IDependencyClass
或者这样做时,可以在没有ContainingClass
注意的情况下进行切换(例如,如果底层访问层发生更改)。
此外,考虑使用基于注释的配置,可以显着减少对单独XML文件的需求,并使其(如果正确完成)更容易跟踪代码,因为必须在XML和Java代码之间切换。