Мы используем фабричный завод Виндзора и думаем, что это прекрасно.Мы используем фабрики на основе интерфейса .Однако мы хотели бы отключить некоторые подмножества фабрик на основе делегатов , в частности неявно зарегистрированных фабрик .Это противоречит интуиции не потому, что они являются делегатами, а потому, что они волшебным образом созданы и могут задержать сбой.
Если у нас есть класс, который принимает делегата в качестве зависимости
class X { public X(Func<int,IPrincipal> d); }
А затем зарегистрируйте его в контейнере, в котором зарегистрировано типовое производственное оборудование.
container.Kernel.Register(Component.For<X>().ImplementedBy<X>())
Я могу разрешить его без каких-либо проблем, что поначалу нелогично, поскольку никто не сказал контейнеру, что у нас есть что-то дляскажем о Func<int,IPrincipal>.
var x = container.Resolve<X>();
И я не столкнусь с ошибкой, пока не попытаюсь реально использовать эту неявно созданную фабрику.
x.D(0); // no registration for IPrincipal
Хотя это имеет смысл с определеннойТочка зрения, тот факт, что эта фабрика неявно создана, является проблематичным.Это очень контейнеросознательное поведение.Люди, которые пишут произвольные классы, сочтут полезным параметризовать свое поведение с помощью делегатов, и как только мы помещаем их в контейнер IoC, мы сталкиваемся с этим удивительным поведением.
Тем не менее существует одна умная неявная фабрика, котораяПохоже, это стоит сохранить.Прямо сейчас Windsor создаст простую фабрику для зависимостей вида Func<T>, позволяющую потребителю зависимости задерживать фактическое создание.В среде 4.0 может иметь смысл изменить это так, чтобы распознавать Lazy<T> как явное указание на то, что вы просто откладываете конструкцию T, а не пытаетесь получить доступ к фабрике, которая будет реализовывать интересную политику.
Есть ли умный переключатель для настройки TypedFactoryFacility или нам нужно реализовать несколько новых объектов, чтобы получить желаемое поведение?