Question

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

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

一个类必须获取spring应用程序上下文。假设您在main（）;

中执行此操作

所以你在main中加载spring，然后希望其余的对象现在很好地注入bean并且可以在没有紧密耦合的情况下进行交互。

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

我想在实践中，你创建了一个包含spring应用程序上下文的全局对象，以便需要执行此操作的类轻松访问，但它仍然看起来有点混乱，与弹簧耦合的弹簧哲学相反？

这只是其中之一吗？它并不完美，但它仍然比你的课程紧密耦合好多了？

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

Answer 1

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

Spring docs for testing are here。

想象一个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的使用，并将责任转移到创建新鲜豆到服务/工厂。

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);
    }
}

NowService：

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被使用，那就差不多了。但是通过工厂，您可以根据自己的内容改变创建流程。

Answer 2

您描述的情况（在每个方法调用中创建对象）通常与创建业务模型对象相关联，使用“new”创建此类对象是完全正确的。

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

Answer 3

我不完全确定我是否正确理解了您的问题，但我认为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了解详细信息。

访问春天的背景

3 个答案: