Как решается проблема зависимостей и компонентов-одиночек(необходимых в одном экземпляре) в клиентских (desktop) приложениях?
Использовать ли реестр, как типовое решение, или попробовать взять контейнер (какой?), реализующий IoC?
Здравствуйте, techgl, Вы писали:
T>Как решается проблема зависимостей и компонентов-одиночек(необходимых в одном экземпляре) в клиентских (desktop) приложениях?
Синглтон запихнуть в контейнер, а контейнер сделать синглтоном, при этом рекомендуется связывать контейнер-синглтон не с процессом, а с логическим или физическим изолирующим контекстом (плагином, потоком, AppDomain-ом в .NET).
T>Использовать ли реестр, как типовое решение, или попробовать взять контейнер (какой?), реализующий IoC?
Если речь идёт о .NET, осмелюсь порекомендовать Microsoft Unity.
Здравствуйте, techgl, Вы писали:
T>Как решается проблема зависимостей и компонентов-одиночек(необходимых в одном экземпляре) в клиентских (desktop) приложениях? T>Использовать ли реестр, как типовое решение, или попробовать взять контейнер (какой?), реализующий IoC?
Используйте контейнер, не пожалеете. К хорошему привыкаешь быстро, а не пользовавшимся шуруповертом всегда будет казаться, что нет никаких проблем закрутить десяток шурупов обычной отверткой.
.Net? Порекомендую Spring.Net, тяжеловат, но в уже первом нашем приложении с его использованием в итоге был использовано более 80% функционала. Причем до использования этого не ожидалось вообще. Т.е. аппетит пришел во время еды.
То, что мне нравится больше всего в нем — внешний конфиг, т.е. код приложения почти не знает о спринге. Впрочем сейчас уже многие DI фреймворки это умеют. Но то, что не пробовал рекомендовать не буду.
Здравствуйте, techgl, Вы писали:
T>Как решается проблема зависимостей и компонентов-одиночек(необходимых в одном экземпляре) в клиентских (desktop) приложениях? T>Использовать ли реестр, как типовое решение, или попробовать взять контейнер (какой?), реализующий IoC?
Имеет смысл использовать Dependency Injection container. Зависимость типа от синглтона не видна "снаружи", снижается прозрачность контракта и снижается легкость изменения, тестируемость.
Например, в Web Client Software Factory в контейнере регистрируется HttpContext, который итак доступн через HttpContext.Current.
В Unity для этих целей есть ContainerControlledLifetimeManager.
Здравствуйте, Ziaw, Вы писали:
Z>Используйте контейнер, не пожалеете. К хорошему привыкаешь быстро, а не пользовавшимся шуруповертом всегда будет казаться, что нет никаких проблем закрутить десяток шурупов обычной отверткой.
Хочу попробовать вариант с типовым решением, сначала. Но контейнер уже присмотрел — PicoContainer. Почитал — DI нормально реализует.
Просто Spring — слишком тяжелое решение для нашего приложения.
Здравствуйте, techgl, Вы писали:
T>Здравствуйте, Ziaw, Вы писали:
Z>>Используйте контейнер, не пожалеете. К хорошему привыкаешь быстро, а не пользовавшимся шуруповертом всегда будет казаться, что нет никаких проблем закрутить десяток шурупов обычной отверткой. T>Хочу попробовать вариант с типовым решением, сначала. Но контейнер уже присмотрел — PicoContainer. Почитал — DI нормально реализует. T>Просто Spring — слишком тяжелое решение для нашего приложения.
Попробуйте для начала NInject -- он чисто контейнер. Аппетит придет, встретитесь с проблемами, поглядите и в сторону Spring.NET -- там много чего может в жизни пригодиться.
