Здравствуйте, _FRED_, Вы писали:
L>>Я и не ратую за чрезмерное использование синглтонов. Один глобальный ServiceLocator — наш выбор.
_FR>Кстати, у вас же ASP, если не ошибаюсь: чем определяются границы "глобальности": доменом или чем-то ещё?
Здравствуйте, _FRED_, Вы писали:
_FR>Site ни одному компоненту (из известных мне) ещё не помешал. Когда же требуется, он заботливо выставляется environment-ом и предоставляет доступ ко всему. А почти всё, что крутится вокруг обработки компонентов имеет доступ к какому-либо компоненту и, следовательно, к его сайту и сервисам. Там же, где компонентов в явном виде нет, в методы передаются _необходимые_ контексты (важно отметить, что контексты нужны независимо от того, есть у нас сервис-провайдер или нет), и какой-то ServiceProvider можно вытащить из такого контекста. Опять же проблем с тем, что "приходится что-то ненужное таскать повсюду" нет: всегда приходится что-то да таскать, передавать данные из одного кода в другой. Часть таких данных и мождно сделать IServiceProvider или любой другой контейнер. Даже то, что зачастую в методы передаётся "голый" IServiceProvider всё-таки не порит какртину, по крайней мере, никакого удивления\неприятия у мен оно не вызывало.
Меня больше интетесует использование ServiceProvider-ов в объектной модели предметной области. Как поступать там? Тащить в каждую сущность ссылку на сервис-провайдер?
Здравствуйте, Lloyd, Вы писали:
L>Меня больше интетесует использование ServiceProvider-ов в объектной модели предметной области. Как поступать там? Тащить в каждую сущность ссылку на сервис-провайдер?
Это, как понимаешь, зависит от того, что и как в предметной области уже сделано. Есть ли какой-то контекст, в котором живут объекты, какой-то коренной объект, из которого они получаются? Что из себя представляют объекты предметной области: наследники какого-то толстого объекта или наоборот, аналоги кортежей с полями, но без логики, которая реализована в отдельных сервисах? Вариантов тьма. Приведи пример, где не получается обойтись без синглетона (или где не красиво\сложно без него) — тогда будет интереснее :о)
Объединяя с предыдущим вопросом:
_FR>>Кстати, у вас же ASP, если не ошибаюсь: чем определяются границы "глобальности": доменом или чем-то ещё? L>Риквестом.
То есть, на каждый реквест заново создаётся локатор, и в него подгружаются (создаются заново или откуда-то бурутся) все сервисы?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Это, как понимаешь, зависит от того, что и как в предметной области уже сделано. Есть ли какой-то контекст, в котором живут объекты, какой-то коренной объект, из которого они получаются? Что из себя представляют объекты предметной области: наследники какого-то толстого объекта или наоборот, аналоги кортежей с полями, но без логики, которая реализована в отдельных сервисах? Вариантов тьма. Приведи пример, где не получается обойтись без синглетона (или где не красиво\сложно без него) — тогда будет интереснее :о)
Тонкий класс с логикой. Базового класса можно считать что нет.
_FR>>>Кстати, у вас же ASP, если не ошибаюсь: чем определяются границы "глобальности": доменом или чем-то ещё? L>>Риквестом.
_FR>То есть, на каждый реквест заново создаётся локатор, и в него подгружаются (создаются заново или откуда-то бурутся) все сервисы?
Здравствуйте, Lloyd, Вы писали:
_FR>>Это, как понимаешь, зависит от того, что и как в предметной области уже сделано. Есть ли какой-то контекст, в котором живут объекты, какой-то коренной объект, из которого они получаются? Что из себя представляют объекты предметной области: наследники какого-то толстого объекта или наоборот, аналоги кортежей с полями, но без логики, которая реализована в отдельных сервисах? Вариантов тьма. Приведи пример, где не получается обойтись без синглетона (или где не красиво\сложно без него) — тогда будет интереснее :о)
L>Тонкий класс с логикой. Базового класса можно считать что нет.
Если с логикой, то уже не тонкий :о) Если "логика" — это методы [пере-]расчёта полей? Нужно ли "логике" ходить в кэш\БД? Теперь про класс: сколько в нём методов "логики"? Несколько? Не больше дестка? Много? Нельзя ли вообще отделить логику от экземпляра, и иметь её отдельно, в специальном сервисе логики, конкретном для определённого класса данных?
_FR>>>>Кстати, у вас же ASP, если не ошибаюсь: чем определяются границы "глобальности": доменом или чем-то ещё? L>>>Риквестом. _FR>>То есть, на каждый реквест заново создаётся локатор, и в него подгружаются (создаются заново или откуда-то бурутся) все сервисы? L>Да, именно так.
А что бы тогда повсюду, где нужно, вместо
var myService = GlobalLocator.Instance.GetService<IMyService>();
не делать так:
var locator = new GlobalLocator();
var myService = locator.GetService<IMyService>();
?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, Lloyd, Вы писали:
_FR>>>Это, как понимаешь, зависит от того, что и как в предметной области уже сделано. Есть ли какой-то контекст, в котором живут объекты, какой-то коренной объект, из которого они получаются? Что из себя представляют объекты предметной области: наследники какого-то толстого объекта или наоборот, аналоги кортежей с полями, но без логики, которая реализована в отдельных сервисах? Вариантов тьма. Приведи пример, где не получается обойтись без синглетона (или где не красиво\сложно без него) — тогда будет интереснее :о)
L>>Тонкий класс с логикой. Базового класса можно считать что нет.
_FR>Если с логикой, то уже не тонкий :о) Если "логика" — это методы [пере-]расчёта полей? Нужно ли "логике" ходить в кэш\БД? Теперь про класс: сколько в нём методов "логики"? Несколько? Не больше дестка? Много? Нельзя ли вообще отделить логику от экземпляра, и иметь её отдельно, в специальном сервисе логики, конкретном для определённого класса данных?
_FR>>>>>Кстати, у вас же ASP, если не ошибаюсь: чем определяются границы "глобальности": доменом или чем-то ещё? L>>>>Риквестом. _FR>>>То есть, на каждый реквест заново создаётся локатор, и в него подгружаются (создаются заново или откуда-то бурутся) все сервисы? L>>Да, именно так.
_FR>А что бы тогда повсюду, где нужно, вместо _FR>
var myService = GlobalLocator.Instance.GetService<IMyService>();
_FR>не делать так: _FR>
_FR>var locator = new GlobalLocator();
_FR>var myService = locator.GetService<IMyService>();
_FR>
_FR>?
Может быть тем, что не надо везде (в рамках одного реквеста) таскать за собой ссылку на этот локатор по всем классам?
Здравствуйте, _FRED_, Вы писали:
L>>Тонкий класс с логикой. Базового класса можно считать что нет.
_FR>Если с логикой, то уже не тонкий :о) Если "логика" — это методы [пере-]расчёта полей? Нужно ли "логике" ходить в кэш\БД? Теперь про класс: сколько в нём методов "логики"? Несколько? Не больше дестка? Много? Нельзя ли вообще отделить логику от экземпляра, и иметь её отдельно, в специальном сервисе логики, конкретном для определённого класса данных?
И что это даст? Если методу класса понабиться например проверить права, то какая разница откуда получать ссылку на SecurityProvider — из объектной модели или из сервисных классов?
_FR>>>То есть, на каждый реквест заново создаётся локатор, и в него подгружаются (создаются заново или откуда-то бурутся) все сервисы? L>>Да, именно так.
_FR>А что бы тогда повсюду, где нужно, вместо _FR>
var myService = GlobalLocator.Instance.GetService<IMyService>();
_FR>не делать так: _FR>
_FR>var locator = new GlobalLocator();
_FR>var myService = locator.GetService<IMyService>();
_FR>
_FR>?
Недостатки этого варианта я вижу, а вот достоинств как-то не наблюдается.
Здравствуйте, Lloyd, Вы писали:
L>>>Тонкий класс с логикой. Базового класса можно считать что нет. _FR>>Если с логикой, то уже не тонкий :о) Если "логика" — это методы [пере-]расчёта полей? Нужно ли "логике" ходить в кэш\БД? Теперь про класс: сколько в нём методов "логики"? Несколько? Не больше дестка? Много? Нельзя ли вообще отделить логику от экземпляра, и иметь её отдельно, в специальном сервисе логики, конкретном для определённого класса данных?
L>И что это даст?
Ты ни на один мой вопрос не ответил Как я могу сказать хоть что-то, что могло бы тебя устроить?
L>Если методу класса понабиться например проверить права, то какая разница откуда получать ссылку на SecurityProvider — из объектной модели или из сервисных классов?
Только та, что в данный момент у тебя для сервисных классов заведён синглетон, от которого ты не наешь, как избавиться.
_FR>>А что бы тогда повсюду, где нужно, вместо _FR>>не делать так:
L>Недостатки этого варианта я вижу, а вот достоинств как-то не наблюдается.
Какие? Не зная подноготной (например, на сколько дорого создание сервисов), я недостатков не вижу А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
L>>Если методу класса понабиться например проверить права, то какая разница откуда получать ссылку на SecurityProvider — из объектной модели или из сервисных классов?
_FR>Только та, что в данный момент у тебя для сервисных классов заведён синглетон, от которого ты не наешь, как избавиться.
Я? Ты меня с кем-то путаешь. У меня заведен один сервис-провайдер, доступ к которому — через синглтон. И избавляться от него у меня нет никакого желания.
_FR>>>А что бы тогда повсюду, где нужно, вместо _FR>>>не делать так:
L>>Недостатки этого варианта я вижу, а вот достоинств как-то не наблюдается.
_FR>Какие? Не зная подноготной (например, на сколько дорого создание сервисов), я недостатков не вижу
А они есть. Как ты в твоем варианте тестирование организуешь?
Если у тебя единственный сервис-контейнер, то просто в начале теста засовываешь в него моки нужных сервисов и запскаешь тест.
А что делать, если создание контейнеров разбросано всюду?
_FR>А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.
Почему отсутствие синглтона является преимуществом?
Здравствуйте, Lloyd, Вы писали:
L>>>Если методу класса понабиться например проверить права, то какая разница откуда получать ссылку на SecurityProvider — из объектной модели или из сервисных классов? _FR>>Только та, что в данный момент у тебя для сервисных классов заведён синглетон, от которого ты не наешь, как избавиться. L>Я? Ты меня с кем-то путаешь. У меня заведен один сервис-провайдер, доступ к которому — через синглтон. И избавляться от него у меня нет никакого желания.
"Не хочешь" и "не знаешь" — разные вещи. Я вижу, что "не хочешь", а судя по этому
сообщению, сделал вывод, что наверняка "не знаешь".
_FR>>>>А что бы тогда повсюду, где нужно, вместо _FR>>>>не делать так: L>>>Недостатки этого варианта я вижу, а вот достоинств как-то не наблюдается. _FR>>Какие? Не зная подноготной (например, на сколько дорого создание сервисов), я недостатков не вижу
L>А они есть. Как ты в твоем варианте тестирование организуешь? L>Если у тебя единственный сервис-контейнер, то просто в начале теста засовываешь в него моки нужных сервисов и запскаешь тест.
Да
L>А что делать, если создание контейнеров разбросано всюду?
Зачем несколько контейнеров? Ну даже если и нужны, то контейнер нужно создавать через фабрику, которая данные читает из конфига. Хоть сотнями создавай, разницы никакой
_FR>>А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.
L>Почему отсутствие синглтона является преимуществом?
Вопрос тут не раз задавался и обсуждений много. Если ты считаешь наличие синглетона преимуществом, спорить не буду, потому что не хочу, но мы сейчас обсуждаем не достоинства \недостатки синглетонов, а то, как от синглетона можно избавиться.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Зачем несколько контейнеров? Ну даже если и нужны, то контейнер нужно создавать через фабрику, которая данные читает из конфига. Хоть сотнями создавай, разницы никакой
_FR>>>А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.
L>>Почему отсутствие синглтона является преимуществом?
_FR>Вопрос тут не раз задавался и обсуждений много. Если ты считаешь наличие синглетона преимуществом, спорить не буду, потому что не хочу, но мы сейчас обсуждаем не достоинства \недостатки синглетонов, а то, как от синглетона можно избавиться.
Вот у тебя значок "эксперт" Поясни, пожалуйста, чем синглтон так плох? Я пока не вижу в нём проблем, если применять по месту.
Здравствуйте, _FRED_, Вы писали:
L>>>>Если методу класса понабиться например проверить права, то какая разница откуда получать ссылку на SecurityProvider — из объектной модели или из сервисных классов? _FR>>>Только та, что в данный момент у тебя для сервисных классов заведён синглетон, от которого ты не наешь, как избавиться. L>>Я? Ты меня с кем-то путаешь. У меня заведен один сервис-провайдер, доступ к которому — через синглтон. И избавляться от него у меня нет никакого желания.
_FR>"Не хочешь" и "не знаешь" — разные вещи. Я вижу, что "не хочешь", а судя по этому
сообщению, сделал вывод, что наверняка "не знаешь".
Если я не вижу выгод от избавления, то и знать не желаю, как от него избавляться.
L>>А они есть. Как ты в твоем варианте тестирование организуешь? L>>Если у тебя единственный сервис-контейнер, то просто в начале теста засовываешь в него моки нужных сервисов и запскаешь тест.
_FR>Да
L>>А что делать, если создание контейнеров разбросано всюду?
_FR>Зачем несколько контейнеров?
Не "несколько контейнеров", а несколько мест, где нужно получить доступ к необходимым нам сервисам.
_FR>Ну даже если и нужны, то контейнер нужно создавать через фабрику, которая данные читает из конфига. Хоть сотнями создавай, разницы никакой
Конфиги — это не так удобно, как кажется. Через конфиг я моки в тестах не сконфигурю.
_FR>>>А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.
L>>Почему отсутствие синглтона является преимуществом?
_FR>Вопрос тут не раз задавался и обсуждений много. Если ты считаешь наличие синглетона преимуществом, спорить не буду, потому что не хочу, но мы сейчас обсуждаем не достоинства \недостатки синглетонов, а то, как от синглетона можно избавиться.
Я этого не обсуждаю. Мне это не интересно.
Про недостатки синглтонов мне известно, обсуждения я эти читал. Да вот только обсуждалась ситуация, когда каждый сервис — синглтон. В моем случае синглтоном является не сервис, а сервис провайдер. Какие здесь недостатки я не вижу.
Здравствуйте, AndrewVK, Вы писали:
AVK>Какой бы он не был конкретный, все одно его надо применять,
Я рекомендую Вам всё-таки посмотреть его сначала. Он крайне прост и удобен в применении, и именно поэтому я не вижу противопоказаний к его использованию.
Здравствуйте, Dog, Вы писали:
Dog>Написали бы лучше сравнение Unity c Autofac.
Статью писать лень Но могу тезисно. Основная фича autofac радующая меня больше всего — грамотная поддержка лямбда-выражений. В Castle и Unity, насколько я помню, сие вообще отсутствует.
Был гораздо белее интресный аргумент.
Как я могу сказать хоть что-то, что могло бы тебя устроить?
и обсуждений много. Если ты считаешь наличие синглетона преимуществом, спорить не буду, потому что не хочу, но мы сейчас обсуждаем не достоинства \недостатки синглетонов, а то, как от синглетона можно избавиться.
Поясни, пожалуйста, чем синглтон так плох? Я пока не вижу в нём проблем, если применять по месту.
