Здравствуйте, Ivan Danilov, Вы писали:

ID>Пусть используется с1. Как только его запросят у IoC-контейнера — тут же будут инстанцированы и с2 и с3. Но что, если с2 и с3 используются только в редких случаях? Получается использование ресурсов вникуда...

ID>Особенно это хорошо заметно, если в качестве компонентов брать формы в WinForms-клиенте. Фактически, получается, что все формы создаются сразу, что создает заметную задержку при старте. Хотя некоторые из этих форм вызываются один-два раза за все время эксплуатации приложения.

Реализовать подобную Facility не особенно сложно — поддержка proxy уже есть. Например, можно взять TypedFactory facility, DynamicProxy для создания Lazy оболочек и написать create метод который будет дергаться через TypedFactory и создавать Proxy для нужного компонента. Или можно взять исходный код TypedFactory и сделать на его основе LazyFactory

ID>Это действительно проблема, или я не заметил какого-то простого решения вопроса?

А насколько правильно регистривать экземпляры форм как компоненты контейнера? У формы может быть куча заморочек с их соданием/удалением, доступом из разных потоков, повторным использованием из нескольких компонент... Не лучше будет регистрировать компонент с названием "менеджер формы" который будет отвечать за ее создание/удаление и т.п? В любом случае, если компонент по своей природе "особо не нужен" то, его можно спросить у контейнера явно.

Есть одна небольшая заминка (хотя, возможно, это я не понимаю что тут к чему).

Пусть имеем такой код (конфиг для Windsor'а очевиден, приводить не буду):

class c1 {
    public c1(c2 a) { ... }
    ...
}

class c2 {
    public c2(c3 b) { ... }
    ...
}

class c3 {
    public c3() { ... }
    ...
}

Пусть используется с1. Как только его запросят у IoC-контейнера — тут же будут инстанцированы и с2 и с3. Но что, если с2 и с3 используются только в редких случаях? Получается использование ресурсов вникуда...

Особенно это хорошо заметно, если в качестве компонентов брать формы в WinForms-клиенте. Фактически, получается, что все формы создаются сразу, что создает заметную задержку при старте. Хотя некоторые из этих форм вызываются один-два раза за все время эксплуатации приложения.

Это действительно проблема, или я не заметил какого-то простого решения вопроса?

Здравствуйте, Ivan Danilov, Вы писали:

ID>Пусть используется с1. Как только его запросят у IoC-контейнера — тут же будут инстанцированы и с2 и с3. Но что, если с2 и с3 используются только в редких случаях? Получается использование ресурсов вникуда...
А как ты себе представляешь создание c1 БЕЗ его зависимостей c2 и с3?

ID>Особенно это хорошо заметно, если в качестве компонентов брать формы в WinForms-клиенте. Фактически, получается, что все формы создаются сразу, что создает заметную задержку при старте. Хотя некоторые из этих форм вызываются один-два раза за все время эксплуатации приложения.
Почему? У тебя что-то неправильно с кодом, который их используется.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Ivan Danilov, Вы писали:

C>А как ты себе представляешь создание c1 БЕЗ его зависимостей c2 и с3?
Простейшее решение — синглтон, который будет инстанцирован только при обращении (ногами не пинать, я просто констатировал факт).
Можно в самом Виндзоре сделать вместо объекта — его прокси, который будет только перенаправлять запросы на реальный объект. А пока запросов нет — вообще ничего не делать.

C>Почему? У тебя что-то неправильно с кодом, который их используется.
Ну представь себе: главная форма и форма настроек. Форма настроек используется главной формой? Используется. Т.е. должна быть отражена в зависимостях — в прототипе конструктора. Но реально настройки используются редко, по сравнению с рабочими формами (один раз настроил и ладно).

Здравствуйте, Ivan Danilov, Вы писали:
ID>Ну представь себе: главная форма и форма настроек. Форма настроек используется главной формой? Используется. Т.е. должна быть отражена в зависимостях — в прототипе конструктора. Но реально настройки используются редко, по сравнению с рабочими формами (один раз настроил и ладно).
Для таких вещей давно придумали lazy loading .

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, Ivan Danilov, Вы писали:
ID>>Ну представь себе: главная форма и форма настроек. Форма настроек используется главной формой? Используется. Т.е. должна быть отражена в зависимостях — в прототипе конструктора. Но реально настройки используются редко, по сравнению с рабочими формами (один раз настроил и ладно).
A>Для таких вещей давно придумали lazy loading .
Осталось только объяснить сию банальную истину Windsor'у
Написать что-ли, команде разработчиков "пожелания к следующей версии"?

Ivan Danilov wrote:
> C>А как ты себе представляешь создание c1 БЕЗ его зависимостей c2 и с3?
> Простейшее решение — синглтон, который будет инстанцирован только при
> обращении (ногами не пинать, я просто констатировал факт).
Синглтон здесь нафиг не нужен — достаточно просто ленивой инициализации.

> C>Почему? У тебя что-то неправильно с кодом, который их используется.
> Ну представь себе: главная форма и форма настроек. Форма настроек
> используется главной формой? Используется. Т.е. должна быть отражена в
> зависимостях — в прототипе конструктора. Но реально настройки
> используются редко, по сравнению с рабочими формами (один раз настроил и
> ладно).
Тут два варианта:
1) Ленивая инициализаци с помощью прокси. Spring.NET так умеет.
2) Явно в коде основной формы делать lookup нужных ресурсов по требованию.
3) Самодельный "ленивый" стаб.

Здравствуйте, Cyberax, Вы писали:

C>Синглтон здесь нафиг не нужен — достаточно просто ленивой инициализации.
Я привел, как один из вариантов. Не имелось в виду, что в такой ситуации его надо использовать.

C>Тут два варианта:
C>1) Ленивая инициализаци с помощью прокси. Spring.NET так умеет.
ну, чуть выше я как раз про этот способ написал.

C>2) Явно в коде основной формы делать lookup нужных ресурсов по требованию.
А это уже не IoC будет...

Да и вообще, мне было интересно именно в контексте Windsor'а... видимо, никак.

Здравствуйте, Ivan Danilov, Вы писали:

ID>А это уже не IoC будет...
IoC.

ID>Да и вообще, мне было интересно именно в контексте Windsor'а...
Ну это уже проблемы Windsor'а, а не IoC.

Здравствуйте, IB, Вы писали:

ID>>А это уже не IoC будет...
IB>IoC.
Если явно передать контейнер главной форме — с натяжкой назвать IoC еще можно. Но стоит появиться еще "подглавной форме", для которой также нужен такой lookup ресурсов — и такой IoC станет больше похож на костыли, чем на паттерн.

Здравствуйте, Ivan Danilov, Вы писали:

ID>Если явно передать контейнер главной форме — с натяжкой назвать IoC еще можно.
Без натяжек.

ID>Но стоит появиться еще "подглавной форме", для которой также нужен такой lookup ресурсов
Такой — это какой?

ID> — и такой IoC станет больше похож на костыли, чем на паттерн.
Ты случаем не путаешь IoC и IoC-контейнер?

Здравствуйте, TK, Вы писали:

TK>...

Спасибо за конструктивный ответ
Первый в этой теме