使用注解注入依賴項會消除依賴項注入（外部配置）的主要好處嗎？

Question

我正在使用 Spring，這里是 controller：

@Controller
public class PersonController {

@Resource(name="PersonService")
private PersonService personService;

    @RequestMapping(value = "/Person", method = RequestMethod.GET)
    public String getPersons(Model model) {

    // Retrieve all persons by delegating the call to PersonService
    List<Person> persons = personService.getAll();

    // Attach persons to the Model
    model.addAttribute("persons", persons);
    //then return to view jsp       
}

這是一項服務：

@Service("personService")
@Transactional
public class PersonService {

    public List<Person> getAll() {
        //do whatever
       }
}

但是，要正確使用 DI，我應該更改 controller 以使用接口（？），如下所示：

@Controller
public class PersonController {

@Resource(name="personService")
private IPersonService personService; //Now an interface
}

例如，這將允許我使用兩項服務，一項是測試服務，一項是實時服務。 我可以通過在服務上添加/刪除注釋來改變：

@Service("personService") // this line would be added/removed
@Transactional
public class LivePersonService implements IPersonService {

    public List<Person> getAll() {
        //do whatever
       }
}

和

@Service("personService") //this line would be added/removed
@Transactional
public class TestPersonService implements IPersonService {

    public List<Person> getAll() {
        //do something else
       }
}

然而，由於必須重新編譯代碼這一事實而失去了主要好處之一？ 而如果我使用 xml 查找，我可以即時更改依賴關系？

Answer 1

配置仍然是外部的，因為它在您定義要注入的實現的外部。 在 class 內部，您只需硬編碼 class所依賴的東西的“名稱” （這沒關系，因為這種依賴關系是類所固有的）。

這就是說，您可以使用 XML 來覆蓋代碼的注釋以執行測試（您將有一個特定的 XML 應用程序上下文用於您的測試）並指定您將注入的實現。

因此，您無需更改代碼即可運行測試。 看看這個答案。

Answer 2

那是正確的。 注釋是源代碼中的配置。 主要用於每個服務都有一個 class 的情況。 如果您對特定接口有多個實現，那么 XML 將是更好的選擇。 您也可以將 XML 配置與注釋混合使用。

Answer 3

我上次從 DI 陣營聽到的傳統方法是，在單元測試中，你不應該使用 DI 框架。 相反，只需自己實例化模擬服務並將其設置為主機 object

test()
    PersonController contr = new PersonController();
    contr.personService = new TestPersonService();
    // testing contr

這被譽為 DI 的第一個也是主要的成就，這讓不明白的人（比如我）非常困惑。 請參閱我之前的批評： 使用 applicationcontext.getbean 與 @configurable 的優勢

如果這個線程中的 DI 支持者反映了 DI 陣營的新趨勢，他們不再那樣做單元測試； 相反，測試也依賴於 DI，具有測試特定的 DI 配置。 那么它真的和服務定位器模式沒有什么不同。 如果 DI 的主要特點是沒有實際意義的，那有什么意義呢？

您的 controller class 完美地說明了這一點。 它不能在 Spring DI 框架之外作為 POJO 使用。 沒有任何關於它的 POJO。 沒有人在乎，這是理所當然的。 如果您的 class 依賴於服務定位器框架，則同樣如此。

Spring beans 框架提供的其他功能，均不依賴於 DI； 它們也可以在服務定位器框架中實現。 很多人在捍衛DI設計模式時，其實是在捍衛Spring整個堆棧。 您實際上可以使用 Spring 作為服務定位器框架； Spring 現在不會做廣告了，這是對其主要炒作點的打擊； 但一旦炒作減弱，它就會吸引懷疑者。