Есть ли в CDI (WELD) эквивалент для построения определений (как это сделано в модулях Guice), а затем для создания инжектора? - PullRequest
Новая
       16

Есть ли в CDI (WELD) эквивалент для построения определений (как это сделано в модулях Guice), а затем для создания инжектора?

19 голосов
/ 15 июня 2010

Мне нравится, как Guice делает довольно простым создание вручную собственных модулей, каждый со своими привязками, сделанными в коде.CDI, с другой стороны, похоже, больше полагается на магию, а не на программный доступ к привязкам Sest.Я ошибаюсь или как можно достичь того же эффекта с WELD.

Любой пример кода будет оценен ...

РАЗЪЯСНЕНИЕ

Я надеялся построить модуль (Термин Guice Извините, я не уверен в термине CDI) программно, используя стиль шаблона компоновщика, заданный Guice для http://code.google.com/p/google-guice/.

Я строю динамическую систему, и мне необходимо иметь возможность связывать типы(например, интерфейсы), константы и т. д., а не просто, чтобы Weld динамически сканировал путь к классам и т. д., находил и регистрировал типы.Я считаю, что CDI является статическим, пакет javax.inject не включает никаких интерфейсов, позволяющих программно связывать типы с реализациями.

РАЗЪЯСНЕНИЕ ЧАСТЬ 2

Основной предпосылкой первоначального вопроса былопростое наблюдение, что аннотации запекаются и правила, определенные в них, чтобы помочь Инъектору, не могут быть изменены.Первоначально я хотел получить открытый доступ к тем же интерфейсам, которые использует сканер пути к классам CDI для создания определений для его внутреннего использования.По сути, я хочу сказать, что я хочу слой, который позволяет мне читать аннотации и создавать определения для контейнера.Поставщиком по умолчанию может быть тот, который делает то, что происходит сейчас, но если вам нужна какая-то другая стратегия, тогда существует возможность сделать это.

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

Example1

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

Представьте себеу одного есть компонент перезаписи URL, который для аргументов имеет некоторые параметры, такие как

  • , замените этот шаблон этим шаблоном.
  • может быть html cleaner

ЕслиВы хотите внедрить этот же компонент с двумя разными правилами замены, но у вас есть застрявший инжектор html.Конечно, есть способы обойти это, но они требуют артефактов, что, конечно, больше кода.

К сожалению, все обязательные правила относятся к классу, а не к экземпляру, поэтому каждый раз, когда вы запрашиваете класс, вы возвращаетесь в значительной степенифункционально эквивалентный экземпляр.

WELD

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

1 Ответ

7 голосов
/ 28 июля 2011

Я регулярно использую Guice и CDI / Seam2.Краткий ответ: нет , CDI не поддерживает программное определение компонента («привязка», как называет его Guice).

CDI использует декларативный подход, при котором контейнер автоматически сканирует определения компонента,Это можно настроить в некоторой степени с помощью «альтернатив», но это не так гибко, как программный подход Guice (где вы можете делать практически все).

Мои два цента

Я использую оба фреймворка: Guice для «низкоуровневых» компонентов POJO, не относящихся к предприятию (где у меня нет / не нужны функции CDI), CDI для всего, где мне нужны дополнительные функции CDI, вещи, которыеподключен к JSF или EJB3.В основном я начал использовать Guice как способ получения DI в JVM-адаптерах, которые работают за пределами кластера серверов приложений.Поскольку я знакомлюсь с CDI, я все меньше нуждаюсь в Guice.Я представляю, что, когда CDI поддерживает «неуправляемые» экземпляры, я могу заменить Guice на CDI (например, weld-se).

RE: Weld 'magic' - IMO, ничто не является 'магией' в сканировании определения бина.Он действительно хорошо определен в спецификации CDI и похож на другие среды Java Enterprise, такие как JPA и EJB3.

Мой совет вам:

  1. Использованиечто работает для вас .Если вам не нравится CDI, не используйте его.Например, мне нужны «неуправляемые экземпляры» в моем приложении, поэтому я использую для этого Guice.
  2. Если вы считаете, что CDI может быть лучше (я так понимаю), присоединяйтесь - участвуйте всообщество, определяющее CDI.
...