2

让我对春天有点困惑的东西。我知道它的一个主要功能是通过提供一种将模块化组件（类）连接在一起的方式来促进模块化和松散耦合，而无需了解其他模块的实现，只知道它们公开的合同。

但是，在实践中，我有时会发现自己处于以下情况。

一个类必须获得 spring 应用程序上下文。假设您在 main();

因此，您在 main 中加载 spring，然后希望您的其余对象现在作为 bean 很好地注入，并且可以在不紧密耦合的情况下进行交互。

但是，如果其中一个对象有一个每次调用时都需要创建一个新 bean 的方法呢？该对象现在需要对 spring 应用程序上下文的引用。但现在它不再是真正的 pojo，因为它与 spring 耦合？

我想在实践中，您创建了一个包含 Spring 应用程序上下文的全局对象，以便需要执行此操作的类轻松访问，但它仍然看起来有点混乱，并且与 Spring 的松散耦合哲学背道而驰？

这只是其中之一吗？它并不完美，但它仍然比让你的类紧密耦合要好得多？

编辑：如果你使用一个全局对象来保存你的 spring 应用程序上下文，你如何对访问它的类进行单元测试？您是否编写了全局持有者，以便可以使用测试上下文对其进行参数化。或者，如果您不使用全局对象，而是将 spring 上下文注入到需要它的类中，这意味着您需要通过代码保持注入 spring 的链，否则您将到达一个点想要一个非弹簧化的对象来创建一个新的 bean，但没有参考弹簧？

4

3 回答 3

3

这是工厂/服务如何提供帮助的人为示例。它使用@Inject，但原理适用于@Autowired等。

用于测试的Spring 文档在这里。

想象一个IsSummerService, 它提供了一种方法来告诉你现在是否是夏天：

public interface IsItSummerService {
    public boolean isItSummerNow();
}

一个简单的第一个 impl 可能如下所示。这个 impl 使用new关键字来管理它的Date依赖关系，并@Inject管理夏季月份范围。这里的Date依赖类似于你创建一个新的 bean。

import java.util.*;
import javax.inject.Inject;

public class IsItSummerServiceImpl1 implements IsItSummerService {
    @Inject int startMonth = Calendar.JUNE;
    @Inject int endMonth = Calendar.SEPTEMBER;
    public boolean isItSummerNow() {
        return DateUtils.isDateBetweenMonths(new Date(), startMonth, endMonth);
    }
}

第二个 impl 可以使用 DI 注入一个NowService（或工厂）。该服务/工厂将取消对 的使用new，并将创建新 bean的责任转交给服务/工厂。

import java.util.*;
import javax.inject.Inject;

public class IsItSummerServiceImpl2 implements IsItSummerService {
    @Inject NowService nowService;
    @Inject int startMonth = Calendar.JUNE;
    @Inject int endMonth = Calendar.SEPTEMBER;
    public boolean isItSummerNow() {
        return DateUtils.isDateBetweenMonths(nowService.now(), startMonth, endMonth);
    }
}

现在服务：

import java.util.Date;

public interface NowService {
    public Date now();
}

那么现在每个测试有多难？无论您在哪里看到“假注入”，都可以通过 Spring 和测试上下文来实现。

的测试IsItSummerServiceImpl2显然更好，更灵活。

import java.text.*;
import java.util.*;
import org.junit.*;

import static org.junit.Assert.*;

public class IsItSummerServiceTest {
    @Test
    public void testIsItSummerImpl1() {
        IsItSummerService s = new IsItSummerServiceImpl1();
        assertFalse(s.isItSummerNow());
        // Test passes for May in the UK
        // But what about when 'now' changes?
        // We can't control the 'now' value effectively to test.
        // assertFalse could pass/fail unpredictably.
        // (Well, it actually *is* predictable when it passes/fails of course!)
    }
    @Test
    public void testIsItSummerImpl2() {
        // You would keep these tests separate, but for the sake of brevity.
        IsItSummerService s = new IsItSummerServiceImpl2();

        // Fake injection - set values directly. Use mocks/stubs/whatever.
        ((IsItSummerServiceImpl2)s).nowService = fakeNowService("01/01/2013");
        assertFalse(s.isItSummerNow());

        ((IsItSummerServiceImpl2)s).nowService = fakeNowService("01/07/2013");
        assertTrue(s.isItSummerNow());
    }
    @Test
    public void testIsItSummerInSouthernHemisphere() {
        // You would keep these tests separate, but for the sake of brevity.
        IsItSummerService s = new IsItSummerServiceImpl2();

        // Fake injection - set values directly. Use mocks/stubs/whatever.
        ((IsItSummerServiceImpl2)s).startMonth = Calendar.DECEMBER;
        ((IsItSummerServiceImpl2)s).endMonth = Calendar.MARCH;

        ((IsItSummerServiceImpl2)s).nowService = fakeNowService("01/11/2013");
        assertFalse(s.isItSummerNow());

        ((IsItSummerServiceImpl2)s).nowService = fakeNowService("01/12/2013");
        assertTrue(s.isItSummerNow());

        ((IsItSummerServiceImpl2)s).nowService = fakeNowService("01/03/2013");
        assertTrue(s.isItSummerNow());

        ((IsItSummerServiceImpl2)s).nowService = fakeNowService("01/04/2013");
        assertFalse(s.isItSummerNow());
    }

    static class FakeNowService implements NowService {
        Date now;
        public FakeNowService(Date now) {
            this.now = now;
        }
        public Date now() {
            return now;
        }
    }

    Date parseDate(String dateStr) {
        try {
            // UK date format
            return new SimpleDateFormat("dd/MM/yyyy").parse(dateStr);
        } catch (ParseException e) {
            throw new RuntimeException(e);
        }
    }

    NowService fakeNowService(String dateStr) {
        return new FakeNowService(parseDate(dateStr));
    }
}

因此，为了回到您的问题，通过从new关键字转移对象创建，我们使应用程序更具可测试性。

new如果您想在以后更改对象创建过程，则不希望使用。用过一次new就差不多了。但是有了工厂，您可以随心所欲地改变创建过程。

于 2013-05-04T10:32:23.187 回答
0

您描述的情况（在每个方法调用中创建对象）通常与创建业务模型对象有关，使用“new”创建此类对象非常好。

Spring IOC (Dependency Injection) 对于非模型对象很重要，因此在实践中您不需要 Spring 上下文以特定方法创建对象，因为这个创建的类不是依赖项。

于 2013-05-04T08:52:54.833 回答
0

我不完全确定我是否正确理解了您的问题，但我认为 bean 范围的定义可能是您的解决方案。

我假设您的方法在每次调用时都需要一个新 bean 的对象属于已经使用 Spring 的 DI 机制来访问 bean。在这种情况下，它可能会使用相应 bean 的原型范围来强制在每次注入时进行新创建 - 请参阅http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference /html/beans.html#beans-factory-scopes-prototype了解详情。

于 2013-05-04T08:59:49.363 回答