Здравствуйте, Воронков Василий, Вы писали:
ВВ>Может я чего-то и не догоняю, но в том что ты описал я не увидел особого отличия от паттерна Service Layer. И сделать сервис-провайдер синглетоном вполне может оказаться куда более удобным чем передача его экземпляра. Т.е. во всем что ты описал — аналог собственно синглтона это та самая "передача экмзепляра", которую вполне и без сервис лаера можно использовать и считать это чем-то более продвинутым чем синглетон мне кажется несколько затруднительным.
Правда? А может ты мне объяснишь как сделать на синглетоне то что я описал.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Зачем IComponent'у IDisposable?
Думаю что бы выбросить самого себя из site. Как я понимаю компонент можно добавить в контейнер его собственного сайта как делается в Dependency Injection, и тогда нужно удалять себя оттуда перед тем как удалиться.
public class Component : MarshalByRefObject, IComponent, IDisposable
{
...
public void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
lock (this)
{
if ((this.site != null) && (this.site.Container != null))
{
this.site.Container.Remove(this);
}
...
}
}
}
...
}
WH>Зачем ISite'у Name и DesignMode?
Понятия не имею
Здравствуйте, WolfHound, Вы писали:
_FR>>Нет, как раз не "протаптывать", а обращаться к тому, какой нужен, раз уж они заранее известны. Просто в приведённой реализации пропадает самая соль "ServiceProvider`а", которая, имхо, в том, что типы (параметра GetService(…) и экземпляра) должны сравниваться не на равенство, а на реализацию, примерно так: WH>То что ты написал это детали реализации которая может быть сколь угодно наворочена. Ничего принципиально они не меняют.
Точно. Увлёкся :о) Попробую ближе к теме:
При использовании такого подхода удалось ли Вам полностью избавиться от синглетонов? Если синглетоны всё же были, то по каким признакам класс попадал в разряд сервисов или "одиночек"?
... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, WolfHound, Вы писали:
WH>Правда? А может ты мне объяснишь как сделать на синглетоне то что я описал.
То, что написал ты, как раз можно, поскольку набор сервисов заранее известен, дело только за "протаптывать его во всех контекстах". И, в принципе, не всегда можно добавить "лишний параметр метода или конструктора"
Но мне предложенная тобой идея тоже сильно понравилась
... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Варвар, Вы писали:
WH>>Зачем IComponent'у IDisposable? В>Думаю что бы выбросить самого себя из site. Как я понимаю компонент можно добавить в контейнер его собственного сайта как делается в Dependency Injection, и тогда нужно удалять себя оттуда перед тем как удалиться.
А если компонент не управляет собственной судьбой? Например еонтейнер сам по запросу сканирует лежащие в нем компоненты и по определенным признакам выкидывает?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _FRED_, Вы писали:
_FR>При использовании такого подхода удалось ли Вам полностью избавиться от синглетонов?
Да. Удалось. _FR>Если синглетоны всё же были,
Был они класс с кучей static методов которые читали и анализировали метаинформацию типов. Потом в этот класс добавили несколько кешей для того чтобы рефлекшен лишний раз не трогать. Была мысль превратить и его в сервис но омобого смысла в этом небыло да и других задач хватало. _FR>то по каким признакам класс попадал в разряд сервисов или "одиночек"?
По глупости.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _FRED_, Вы писали:
_FR>То, что написал ты, как раз можно, поскольку набор сервисов заранее известен, дело только за "протаптывать его во всех контекстах".
Как сделать так чтобы на корне могло быть несколько сессий? В каждой сессии могло быть несколько отображений? При этом у каждой сессии и отображения должна быть своя копия сервисов.
_FR>И, в принципе, не всегда можно добавить "лишний параметр метода или конструктора"
Просто проектировать нужно в расчете на это.
Кстати Варвар дал хорошую ссылку в этом
Здравствуйте, Воронков Василий, Вы писали:
WH>>Правда? А может ты мне объяснишь как сделать на синглетоне то что я описал. ВВ>Сделать сервис-провайдер синглетоном?
И? Как ты для каждой сессии заведешь свою копию сервисов уровня сессии?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>И? Как ты для каждой сессии заведешь свою копию сервисов уровня сессии?
Гм, тебе не кажется что это уже другой вопрос и к синглетону как таковому отношения не имеет? Все что я хотел сказать — это то что сервис провайдер как таковой никак не противоречит синглетону ни в классическом его смысле, ни в неклассическом (см. например ремотинг, куда этот паттерн прекрасно подходит).
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Гм, тебе не кажется что это уже другой вопрос и к синглетону как таковому отношения не имеет? Все что я хотел сказать — это то что сервис провайдер как таковой никак не противоречит синглетону ни в классическом его смысле, ни в неклассическом (см. например ремотинг, куда этот паттерн прекрасно подходит).
Нет не кажется. Как ты думаешь почему я и не только я послал синглитоны в лес?
Просто по тому что они очень сильно связывают программу, а сильная связанность ничего кроме гемороя не дает.
Например смотри мое сообщение
как ты думаешь если бы логер сделали синглитоном (что очень часто с ним и делают) то можно было бы также легко добавить информацию о сессии в контексте которой происходит запись в лог?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Нет не кажется. Как ты думаешь почему я и не только я послал синглитоны в лес? WH>Просто по тому что они очень сильно связывают программу, а сильная связанность ничего кроме гемороя не дает.
Т.е. то что ты предлагаешь — это универсальное решение, которое всегда можно и нужно использовать вместо синглетонов? В противном случае я не понимаю, о чем спор.
WH>Например смотри мое сообщение
как ты думаешь если бы логер сделали синглитоном (что очень часто с ним и делают) то можно было бы также легко добавить информацию о сессии в контексте которой происходит запись в лог?
Прекрасно. Никто же не говорит, что нужно всегда использовать синглтоны. Приводить примеры где синглтон будет кстати? Просто ты привел решение, которое никак не заменяет и вообще полностью перпендикулярно синглтонам.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Т.е. то что ты предлагаешь — это универсальное решение, которое всегда можно и нужно использовать вместо синглетонов? В противном случае я не понимаю, о чем спор.
Именно.
ВВ>Прекрасно. Никто же не говорит, что нужно всегда использовать синглтоны. Приводить примеры где синглтон будет кстати? Просто ты привел решение, которое никак не заменяет и вообще полностью перпендикулярно синглтонам.
Попробуй.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ВВ>>Прекрасно. Никто же не говорит, что нужно всегда использовать синглтоны. Приводить примеры где синглтон будет кстати? Просто ты привел решение, которое никак не заменяет и вообще полностью перпендикулярно синглтонам. WH>Попробуй.
Да все очень просто — требуется глобальный инстанс в домене (или даже не только в домене) приложения. Примеры — файл конфига, глобальный сервис провайдер (например, в случае если этот паттерн используется при работе с плагинами), сервис ремотинг, фасад слоя доступа к данным и пр.
Как только мы попробуем сущности, изначально расчитанные на "общий" доступ, передвать каким-либо образом вместо того, чтобы делать их статиками/синглетонами, то свяжем весь остальной код не меньше, обязав его следовать определенному контракту — реализовывать специальным образом конструктор или определять специальный метод — что тоже особенно не весело.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Да все очень просто — требуется глобальный инстанс в домене (или даже не только в домене) приложения.
Эта модель не препятствует сервису быть в одном экземпляре. ВВ>Примеры — файл конфига,
Допустим мы пишем IDE... на каждый проект по проектному файлу...
А если программа поддерживает несколько пользователей? А если эти пользователи могут быть залогинины одновременно?
Так сколько у нас конфигов? ВВ>глобальный сервис провайдер (например, в случае если этот паттерн используется при работе с плагинами),
Ну да конечно, а про то что у нас в разных проектах разные языки программирования и им нужен разный интелисенс мы и забыли. ВВ>сервис ремотинг,
С ним дел не имел. ВВ>фасад слоя доступа к данным и пр.
Вот ведь как нехорошо то получается... некоторые сесии хотят чтобы обращения к базе логировались... другие хотят блокировать некоторые запросы которые идут от бизнес логики, а третьи сессии вот ведь гады какие полезли в другую базу...
ВВ>Как только мы попробуем сущности, изначально расчитанные на "общий" доступ, передвать каким-либо образом вместо того, чтобы делать их статиками/синглетонами, то свяжем весь остальной код не меньше, обязав его следовать определенному контракту — реализовывать специальным образом конструктор или определять специальный метод — что тоже особенно не весело.
Тут два варианта
1)Использовать синглетоны и статики:
+Меньши возьни в тривиальных случаях.
-Вешалка в нетривиальных случаях.
2)Использовать то что я описал:
-Больше возьни в тривиальных случаях.
+Можно разрулить большинство нетривиальных случаев не напрягаясь.
Не знаю как у тебя, а у меня встречаются все больше нетривиальные случаи. К томуже если мы уж начали использовать такую схему то она в любом случае прошьет всю программу... и тогда уж точно не будет никакого смысла использовать синглетоны.
Итого: Никаких принципиальный преймущест синглитонов ты так и не продемонстрировал.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Вот ведь как нехорошо то получается... некоторые сесии хотят чтобы обращения к базе логировались... другие хотят блокировать некоторые запросы которые идут от бизнес логики, а третьи сессии вот ведь гады какие полезли в другую базу...
А вот если нет таких сессий? И приложение однопользовательское — или уж, во всяком случае, не допускает несколько одновременно залогиненных пользователей? И что-то мне сдается, что это куда более распространенный вариант, чем ты описываешь.
Ни разу кстати не писал локальный дата-лаер с которым работает одновременно несколько различных сессий с разными требованиями к фунцкиональности.
WH>Не знаю как у тебя, а у меня встречаются все больше нетривиальные случаи. К томуже если мы уж начали использовать такую схему то она в любом случае прошьет всю программу... и тогда уж точно не будет никакого смысла использовать синглетоны.
А у меня — наоборот — больше тривиальные. В итоге — нашли ли мы silver bullet?
Здравствуйте, WolfHound, Вы писали:
_FR>>то по каким признакам класс попадал в разряд сервисов или "одиночек"? WH>По глупости.
Имеется в виду в разряд "одиночек" по глупости.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А вот если нет таких сессий? И приложение однопользовательское — или уж, во всяком случае, не допускает несколько одновременно залогиненных пользователей? И что-то мне сдается, что это куда более распространенный вариант, чем ты описываешь.
Не будет сессий будет что-то другое что без такой механики делаль задолбаешься. А если уж завели эту механику то... ВВ>Ни разу кстати не писал локальный дата-лаер с которым работает одновременно несколько различных сессий с разными требованиями к фунцкиональности.
А у меня было. И кто сказал что это обязательно должен быть клиент? Может это сервер?
ВВ>А у меня — наоборот — больше тривиальные. В итоге — нашли ли мы silver bullet?
Их как извесно не бывает. Вот только я предпочитаю ходить с пистолетом даже если в нем обыкновенные пули нежели с дубинкой.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Вообще то тема не о том, пользоваться синглтонами или нет, а о том что если уж пользоваться, то делать их классическими, или же просто статическими функциями. Я за статики, хотя для частных случаев классики тоже имеют право на жизнь
ЗЫ. Можно разделить тему и продолжить в отдельной ветке обсуждать component-conteiner-service модель.
Здравствуйте, WolfHound, Вы писали:
_FR>>То, что написал ты, как раз можно, поскольку набор сервисов заранее известен, дело только за "протаптывать его во всех контекстах". WH>Как сделать так чтобы на корне могло быть несколько сессий? В каждой сессии могло быть несколько отображений? При этом у каждой сессии и отображения должна быть своя копия сервисов.
Да, например, синглетоном иметь словарь — сессия — что-то ещё Ну это и впрямь не так важно.
_FR>>И, в принципе, не всегда можно добавить "лишний параметр метода или конструктора" WH>Просто проектировать нужно в расчете на это.
Мне очень понравилось то, как это сделано через ObjectBuilder в EnterprizeLibrary — никаких лишних параметров, только открытые свойства, аттрибуты которых говорят о том, что в них нужно записать при построении объекта.
WH>Кстати Варвар дал хорошую ссылку в этом
