Обязательный одиночный элемент к многочисленным услугам в Ninject
У меня есть проблема, которая кажется очень похожей на тот, описанный в http://markmail.org/message/6rlrzkgyx3pspmnf, который является об одиночном элементе, на самом деле создающем больше, чем единственный экземпляр, если Вы получаете доступ к нему с помощью различных сервисных типов.
Я использую последний выпуск Ninject 2 для Компактной Платформы и точной проблемы, которую я имею, это, если я связываю тот же метод поставщика с:
Func serviceCreator = () => new Service(false);
kernel.Bind().ToMethod(serviceCreator).InSingletonScope();
kernel.Bind().ToMethod(serviceCreator).InSingletonScope();
Это, кажется, создает 2 экземпляра Сервиса, если я решаю и как IService и как Сервис.
Это вызывает круговое исключение зависимости при разрешении Сервиса.
Это дизайном, или действительно ли это - ошибка?
1 ответ
В V3, наконец, есть решение для этого в виде новых перегрузок на Bind, смотрите этот связанный: вопрос.
Если вы хотите, чтобы синглтон был общим, вам нужно изменить второй Bind на:
kernel.Bind<Service>().ToMethod(()=>kernel.Get<IService>()).InSingletonScope();
О круговых ссылках и путанице и т.д. Внутренне неявное самопривязывание добавит неявную регистрацию привязки для Service. Вы должны опубликовать исключение.
EDIT: По поводу вашего комментария. Если сделать так:
Func<Service> serviceCreator = () => new Service(false);
kernel.Bind<Service>().ToMethod(serviceCreator).InSingletonScope();
kernel.Bind<IService>().ToMethod(()=>kernel.Get<Service>()).InSingletonScope();
Тогда неявное самопривязывание класса не генерируется, когда IService решается - используется существующее.
В последние недели здесь на SO был еще один вопрос, кто-то делал подобное, но столкнулся с проблемой IInitializable - в том примере было бы правильное упорядочивание, но приведенный выше пример имеет смысл, исходя из моего чтения исходного текста и способа, которым он генерирует неявные самопривязки классов.