Внедрение зависимостей с Guice: то, что не рассматривается ни в одном учебном пособии - PullRequest
8 голосов
/ 24 июня 2009

Я просто возился с Google Guice для внедрения зависимостей и начал интегрировать его в мое существующее приложение. Все идет нормально. У меня есть много классов, которые нуждаются, помимо их зависимостей, в строках, источниках данных и так далее. Я знаю, что есть NamedBindings, но я действительно не хочу создавать аннотацию для каждой простой строки, которую я должен передать конструктору для каждого класса. Затем есть вещь, называемая AssistedInject, которая создает реализации Factory для меня. Ничего себе, но я все еще должен определить интерфейс фабрики. Это нормально для классов, которые имеют зависимости, но как насчет этого примера класса:

public class FooBarClass {
    public FooBarClass(String name, String anotherOne) {
        // Some stuff
    }
}

В некоторых случаях я сомневаюсь, как правильно использовать Guice или, в более общем смысле, DI. «Часто слышу: XYZ Framework - это новый новый ». Но это подразумевает, что мне нужно создать каждый экземпляр с DI-фреймворком.

Требуется только один экземпляр

Что если мне нужен только один экземпляр этого класса? Этот класс не имеет абсолютно никаких зависимостей, кроме двух строк. Подумайте о крюке отключения, который будет создан только один раз и передан в JVM как мой крюк отключения. Должен ли я создать этот экземпляр с Guice? Это выглядит очень глупо для меня, потому что вводить нечего, но мне нужно написать заводской интерфейс для передачи обоих параметров Guide и создать интерфейс для моего FooBarClass для использования DI.

Требуется несколько экземпляров

То же самое относится и к случаю, когда мне нужно несколько экземпляров этого класса. Никаких зависимостей, но я должен создать кучу шаблонного кода, чтобы ничего не получить от него. Мне кажется, это неправильно.

Итак, как мне использовать DI и / или Guice?

Большое спасибо!

Ответы [ 3 ]

23 голосов
/ 25 июня 2009

Это может помочь разделить зависимости от данных .

  • Зависимости часто представляют собой службы: базы данных, часы и заглушки RPC. Плюс ко всему наложен код приложения: UserAuthenticator, PaymentHandler и EmailGateway.
  • Данные - это просто: Date, Map<String,InetAddress> или даже Customer. Это простые доменные объекты в памяти.

DI, естественно, лучше всего подходит для зависимости от вещей. Вы должны продолжать использовать new для классов вашей модели данных.

2 голосов
/ 14 июля 2009

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

2 голосов
/ 09 июля 2009

если вы создаете несколько экземпляров, таких как отдельные клиенты, не имеет смысла внедрять их. имеет смысл создать CustomerFactory, которая может быть областью @Singleton, которая может создавать экземпляры Customer со всеми своими зависимостями.

...