CDI производит по сравнению с шаблоном локатора сервисов

Я бы меньше думал о том, как получить Service-Proxy, в этом случае оба ваших сценария будут работать одинаково (как вы уже выяснили, вы даже можете аннотировать свой ServiceLocator с помощью @Produces).

Подумайте о том, как класс, использующий Сервис, получит экземпляр прокси. Вы хотите прочитать свойства и найти службу в каждом конструкторе? Будет ли у вас фабрика с одним методом для каждой реализации? Загрузка SPI-сервиса? Как вы собираетесь тестировать классы с помощью сервиса?

Во всех этих случаях внедрение зависимостей имеет большое преимущество, поскольку оно разделяет проблемы и определяет четкие зависимости между клиентом и реализацией. Моя лучшая практика: всякий раз, когда у вас есть выбор, выбирайте (C)DI. Если вы объедините подход ServiceLocator/PropertyReader с аннотацией @Produces, у вас даже не будет больше классов для написания, но вы получите много взамен.

Итак, я создал несколько классов для CDI. Он выглядит красиво и отлично работает.

класс квалификатора с типами:

@Qualifier
@Retention(RUNTIME)
@Target( {TYPE, METHOD, FIELD, PARAMETER} )
public @interface DaoQualifier
{
    public enum DatasourceType { FILE, JPA, MEMORY }

    public DatasourceType type();
}

factory, он возвращает правильный экземпляр интерфейса:

@ApplicationScoped
public class ConfigurationReaderDaoFactory implements Serializable
{
    private static final long serialVersionUID = -7097322271912690164L;
    private static final Logger LOGGER = Logger.getLogger( ConfigurationReaderDaoFactory.class.getName() );
    private final String LOG_MESSAGE = "getting ConfigurationReaderDao ejb remote reference for %s datasource";

    @Produces
    @DaoQualifier(type = DatasourceType.MEMORY)
    public ConfigurationReaderDao getMemoryDao() throws NamingException
    {
        LOGGER.finer( String.format(LOG_MESSAGE,  DatasourceType.MEMORY) );

        String jndi = ""java:global/earName/ejbName/MemoryConfigurationReaderDao!a.b.c.ConfigurationReaderDao";";
        return (ConfigurationReaderDao) InitialContextGenerator.getInitialContext().lookup(jndi);
    }

    @Produces
    @DaoQualifier(type = DatasourceType.JPA)
    public ConfigurationReaderDao getJpaDao() throws NamingException
    {
        LOGGER.finer( String.format(LOG_MESSAGE,  DatasourceType.JPA) );

        String jndi = ""java:global/earName/ejbName/JpaConfigurationReaderDao!a.b.c.ConfigurationReaderDao";";
        return (ConfigurationReaderDao) InitialContextGenerator.getInitialContext().lookup(jndi);
    }
    ...
}

легко использовать его с аннотацией @Inject:

public class ConfigurationReaderService
{
    @Inject
    @DaoQualifier(type = DatasourceType.MEMORY)
    private ConfigurationReaderDao configurationReaderDaoService;

    public String getStringSystemParam(final String key)
    {
        String value = null;

        if (key != null)
        {
            value = configurationReaderDaoService.getStringSystemParam(key);
        }
    }
}

Мне нравится это решение, потому что его легко читать и понимать.

У меня осталось только три вопроса:

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

@Inject
@DaoQualifier(type = DatasourceType.MEMORY)
private ConfigurationReaderDao configurationReaderDaoService;

Параметр типа исходит из конфигурации приложения, которой управляет администратор. Так что мне как-то нужно динамически ввести правильную реализацию интерфейса, и это зависит от простого значения строковой переменной.

Я думаю, мне нужно как-то использовать аннотацию @Any.

(2) Я пытался использовать аннотацию @RequestScoped в начале класса ConfigurationReaderDaoFactory, но это не сработало. Я получил WELD-001303: нет активных контекстов для исключения типа javax.enterprise.context.RequestScoped.

(3) Почему в моем случае использование CDI-инъекции лучше, чем использование непосредственно моего класса ConfigurationReaderDaoFactory? Если я использую свой фабричный класс напрямую, мне не нужен класс DaoQualifier, и мне не нужно выяснять процесс динамического внедрения. Меньше класса и кода всегда лучше :-)