Устраняет ли использование аннотаций для внедрения зависимостей главное преимущество внедрения зависимостей (внешняя конфигурация)? - PullRequest
6 голосов
/ 01 июля 2011

Я использую Spring, вот контроллер:

@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
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, я мог бы изменить зависимость на лету?

Ответы [ 3 ]

4 голосов
/ 01 июля 2011

Конфигурация все еще внешняя, потому что находится снаружи, где вы определяете, какая реализация будет внедрена.Внутри класса вы просто жестко кодируете "имя" из что-то , класс зависит от (что нормально, поскольку эта зависимость присуща классу).

При этом вы можете использовать XML для переопределения аннотаций вашего кода для выполнения тестов (у вас будет определенный контекст приложения XML для ваших тестов) и указать, какую реализацию вы будете внедрять.

Следовательно, вам не нужно менять код для запуска тестов.Посмотрите на этот ответ .

2 голосов
/ 01 июля 2011

Ну, это правильно. Аннотации - это конфигурация внутри исходного кода. В основном предназначен, когда у вас есть один класс для каждой услуги. Если у вас есть несколько реализаций для конкретного интерфейса, тогда XML будет лучшим вариантом. Также вы можете смешивать настройки XML с аннотациями.

0 голосов
/ 02 июля 2011

Обычный способ, который я слышал в прошлый раз из лагеря DI, заключается в том, что в модульных тестах не следует использовать инфраструктуру DI.Скорее, просто создайте экземпляр службы mock самостоятельно и установите его для хост-объекта

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

Это было провозглашено как первое и главное достижение DI, к большому удивлению людей (таких как я), которые не получаютЭто.Смотрите мои предыдущие критические замечания: преимущество использования applicationcontext.getbean против @ configurable

Если сторонники DI в этой теме отражают новую тенденцию в DI camp, они больше не проводят юнит-тесты таким образом;вместо этого тесты также зависят от DI, с конкретной конфигурацией DI.Тогда это действительно ничем не отличается от шаблона поиска сервисов.Если основной особенностью DI является спорный вопрос, то в чем смысл?

Ваш класс контроллеров прекрасно это иллюстрирует.Он не может использоваться вне Spring DI Framework как POJO.В этом нет ничего POJO.И никому нет дела, по праву.То же самое, если ваш класс зависит от структуры локатора службы.

Существуют другие функции, предоставляемые средой EJB-компонентов, ни одна из которых не зависит от DI;они также могут быть реализованы в структуре локатора службы.Многие люди, защищая DI шаблон проектирования, на самом деле защищают Spring весь стек.На самом деле вы можете использовать Spring в качестве фреймворка для поиска сервисов;Spring не будет рекламировать это сейчас, это удар по своей главной точке обмана;но как только шумиха ослабнет, она должна обратиться к сомневающимся.

...