Как делает Единицу. Твердость знает который конструктор использовать?
Учитывая класс с несколькими конструкторами - как я могу сказать Твердость который конструктор использовать?
Рассмотрите следующий класс в качестве примера:
public class Foo
{
public Foo() { }
public Foo(IBar bar)
{
Bar = bar;
}
public Foo(string name, IBar bar)
{
Bar = bar;
Name = name;
}
public IBar Bar { get; set; }
public string Name { get; set; }
}
Если я хочу создать объект типа Foo, использующий Твердость, как Твердость будет знать который конструктор использовать? И как я могу сказать этому использовать правильный? Скажем, у меня есть контейнер с зарегистрированным IBar - он поймет, что он должен способствовать конструктору, берущему IBar? И если я указываю, что строка также - будет он использовать (string, IBar) конструктор?
Foo foo = unityContainer.Resolve<Foo>();
И проигнорируйте то, что, вероятно, было бы легче, если бы класс просто имел единственного конструктора...
2 ответа
Когда целевой класс содержит более одного конструктора, Unity будет использовать тот, к которому применен атрибут InjectionConstructor. Если имеется более одного конструктора, но ни один из них не содержит атрибута InjectionConstructor, Unity будет использовать конструктор с наибольшим количеством параметров. Если таких конструкторов более одного (более одного самого "длинного" с одинаковым количеством параметров), Unity выдаст исключение.
Взято из текста ссылки
Когда вы регистрируете тип, вы можете указать, какой конструктор использовать следующим образом:
container.RegisterType<Foo>(
new InjectionConstructor(
new ResolvedParameter<IBar>()));
Выше код взят из памяти, но это общий принцип. В этом случае я выбрал конструктор, который принимает единственный параметр типа IBar.
И, пожалуйста, не обращайте внимания на тот факт, что, вероятно, было бы проще, если бы у класса был только один конструктор ...
Я не могу игнорировать это. Когда дело доходит до Constructor Injection, двусмысленность - это запах дизайна. Вы в основном говорите: Я действительно не знаю, волнует ли меня эта зависимость или нет.
Конечно, Unity, скорее всего, разберется в этом за вас, но тогда вы будете полагаться на конкретное поведение контейнера вместо того, чтобы правильно проектировать свой API. Другие контейнеры могут вести себя иначе , поэтому, если вы когда-нибудь решите перейти с Unity на более качественный контейнер, могут возникнуть небольшие ошибки.
Намного безопаснее писать код в DI-дружественной, но не зависящей от контейнеров манере.