Microsoft.Practices.ServiceLocation и TryGetInstance - PullRequest
1 голос
/ 12 апреля 2010

Почему Microsoft.Practices.ServiceLocation.IServiceLocator не предлагает TryGetInstance ()?

Мне нужно получить общий экземпляр валидатора ServiceLocator.Current.GetInstance<IEntityValidator<TEntity>>(), но не во всех сущностях зарегистрирован валидатор.

Единственное решение, которое я нашел, это использовать блок try {} catch {}, но мне не нравится этот подход.

Ответы [ 2 ]

4 голосов
/ 12 апреля 2010

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

Если вам нужен IEntityValidator<Foo>, запросите зависимость через конструктор:

public class Foo
{
    private readonly IEntityValidator<Foo> validator;

    public Foo(IEntityValidator<Foo> validator)
    {
        this.validator = validator;
    }
}

Вы можете решить проблему, связанную с тем, что не во всех сущностях зарегистрированы валидаторы по-разному.

Мой предпочтительный подход - зарегистрировать Null Validator для всех этих объектов.

В качестве альтернативы, вы можете дать своим сущностям перегрузку конструктора, которую не не получит валидатор, а затем назначить нулевой валидатор из этого конструктора. Это может выглядеть так:

public class Foo
{
    private readonly IEntityValidator<Foo> validator;

    public Foo()
    {
        this.validator = new NullValidator<Foo>();
    }

    public Foo(IEntityValidator<Foo> validator)
    {
        this.validator = validator;
    }
}

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

В любом случае, подход на основе push равен true Dependency Injection . При таком подходе вы используете DI-контейнер, чтобы разрешить весь граф зависимостей за один проход в точке входа приложения .

3 голосов
/ 12 апреля 2010

Причина, по которой это не поддерживается CSL, заключается в том, что не все платформы IoC поддерживают этот механизм. В дискуссионном форуме Common Service Locator есть обходной путь для этой проблемы. Прочтите этот вопрос .

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...