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

PM>На замену Singletone можно использовать ServiceLocator
PM>здесь
PM>Но там достаточно муторное объяснение. Смысл в том, что сам Locator — это Singleton,

Ага, дабы избавиться от нескольких синглетонов, давайте заведём один, и все синглетоны в него засунем и обзавём модным словом Если бы это было так, то пользы много не давало бы.

Хочешь верь, хочешь не верь, но можно обойтись совсем без глобальных статический переменных с изменяемым состоянием. И даже _сложного_ в этом ничего нет, не то что _очень сложного_.

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

EF>Народ подскжаите как в C# создать Singleton класс?

ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

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

AVK>>Он используется в EJB, но точно так же используется и в куче других мест. И в BCL его реализация тоже есть.

PM>Да? А где?

IServiceProvider, IServiceContainer, ServiceContainer

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

Dog>Написали бы лучше сравнение Unity c Autofac.
Статью писать лень Но могу тезисно. Основная фича autofac радующая меня больше всего — грамотная поддержка лямбда-выражений. В Castle и Unity, насколько я помню, сие вообще отсутствует.

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

PM>1. Во-первых, ServiceLocator — паттерн, являющийся частью концепции EJB

Он используется в EJB, но точно так же используется и в куче других мест. И в BCL его реализация тоже есть.

PM> Не вижу больших минусов в использовании его в проектах малого-среднего размера.

Его это кого?

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

EF>Народ подскжаите как в C# создать Singleton класс?

Обычный static класс..

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

AS>У меня в системе синглетоном ещё логгер реализован.

Вот это как раз то, что многим противникам синглетона и не нравится
Если интересно, то Что не так с синглтоном...

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

Dog>Написали бы лучше сравнение Unity c Autofac. Был гораздо белее интресный аргумент.

Если знаком хоть с одним из двух, разницу понять не сложно за день работы. Если ни знаком ни с одним, то не всё ли равно, что с чем сравнивать..?

Народ подскжаите как в C# создать Singleton класс?

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

EF>Народ подскжаите как в C# создать Singleton класс?

В рамках одного домена:

public static class Singleton<T>
{
  static Singleton()
  {
    Instance = default(T);
  }

  public T Instance { get; private set; }
}

// второй вариант
public static class Singleton<T>
{
  static Singleton()
  {
    Instance = (T)Activator.CreateInstance();
  }

  public T Instance { get; private set; }
}

// третий вариант
public static class Singleton<T>
{
  public Initialize(params object[] args)
  {
    // сюда дабл-лок и вызов необходимого конструктора
    // код дома, на память не могу вспомнить, студии нет.
  }

  public T Instance { get; private set; }
}

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

EF>Народ подскжаите как в C# создать Singleton класс?

Кажется, вас тут избаловали совсем
Не поддавайтесь

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

EF>Народ подскжаите как в C# создать Singleton класс?

здесь

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

EF>>Народ подскжаите как в C# создать Singleton класс?

K>Обычный static класс..

Синглетон — тип, который может иметь одно-единственное значение. Статический же класс значение не имеет совсем. Если это не понятно, пример другой: синглетон может реализовать какой-либо интерфейс, и экземпляр синглетона может быть передан в какой-либо метод в качестве значения параметра. Со статическим классом это невозможно.

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

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

EF>>Народ подскжаите как в C# создать Singleton класс?

_FR>ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

Мне не понятен смысл DBNull.Value, но да, пример синглетона хороший.

У меня в системе синглетоном ещё логгер реализован.

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

_FR>ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

Хорошо если отойти от синглов, то как например реализовать настройку приложения (класс с параметрами и прочее?) котоырй тока один раз должен инититься?

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

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

_FR>>ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

EF>Хорошо если отойти от синглов, то как например реализовать настройку приложения (класс с параметрами и прочее?) котоырй тока один раз должен инититься?

На замену Singletone можно использовать ServiceLocator

здесь

Но там достаточно муторное объяснение. Смысл в том, что сам Locator — это Singleton, а он уже по требованию раздает ссылки на другие объекты. Запрос происходит по типу интерфейса, объект класса, который реализует интерфейс нужно получить. В Вашем примере доступ будет выглядеть примерно так.

IApplicationSettings = ServiceLocator.GetInstance<IApplicationSettings>();

Но конкретно для Settings есть стандартные механизмы )) Но для других сервисов — очень удобно использовать, поскольку контролируемо время инициализации, хотя бы.

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

PM>Но конкретно для Settings есть стандартные механизмы ))

А какие, если это не тайна покрытая мраком? =)

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

_FR>>ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

EF>Хорошо если отойти от синглов, то как например реализовать настройку приложения (класс с параметрами и прочее?) котоырй тока один раз должен инититься?

А подчти так жею То есть, пишем класс с настройками (кстати, с 2005-ой студии такой уже есть сам):

class MyAppConfig
{
}

Так же делаем класс приложения:

class MyApp
{
  public MyAppConfig Config { get; private set; }
}

И начинаем:

static void Main()
{
  MyApp app = new MyApp(); // "Главный" объект - один, не статический глобальный, а локальная переменная
  app.Run(…); // Как-то запускаем
}

Далее, в каждый класс, которому это необходимо, _явно_ передаём или MyApp или MyAppConfig. Для небольшого приложения сойдёт. В большом уже потребуется Dependency Injection Container. И ни одной глобальной переменной. ВсЁ, что объекту нужно в него и передаётся.

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

PM>>Но конкретно для Settings есть стандартные механизмы ))

EF>А какие, если это не тайна покрытая мраком? =)

Managing Application Settings

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

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

_FR>Далее, в каждый класс, которому это необходимо, _явно_ передаём или MyApp или MyAppConfig. Для небольшого приложения сойдёт. В большом уже потребуется Dependency Injection Container. И ни одной глобальной переменной. ВсЁ, что объекту нужно в него и передаётся.

Ответ сразу к двум постам. Я прекрасно знаю и понимаю, но:
1. Во-первых, ServiceLocator — паттерн, являющийся частью концепции EJB, что , по сути, и является реализацией IoC.
2. Во-вторых, это просто удобно, гораздо удобнее чем передавать ссылки во все объекты создаваемые Не вижу больших минусов в использовании его в проектах малого-среднего размера.

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

_FR>Хочешь верь, хочешь не верь, но можно обойтись совсем без глобальных статический переменных с изменяемым состоянием. И даже _сложного_ в этом ничего нет, не то что _очень сложного_.

Расскажи, интересно.

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

AS>У меня в системе синглетоном ещё логгер реализован.

Чем это в твоем случае лучше чем статическими методами?

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

_FR>>Хочешь верь, хочешь не верь, но можно обойтись совсем без глобальных статический переменных с изменяемым состоянием. И даже _сложного_ в этом ничего нет, не то что _очень сложного_.
L>Расскажи, интересно.

О том, как обойтись без глобальных переменных?

Если по-простому: не заводить таковых. Как? В функции Main создаются необходимые локальные переменные (обычно, одна-единственная). У неё вызывается какой-нить Run. Далее: все данные — это поля (не статические) этой переменной. В качестве одного такого может быть DI-контейнер. Необходимые данные (контейнер или конкретика) передаются в объекты в параметрах конструктора\сеттреах свойств и т.п.

Например, создавай приложение через Smart Client Software Factory: довольно развесистое, но без глобальных переменных.

Это всё, думаю, тебе известно Ты какие-то конкретные трудности видишь?

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

_FR>Если по-простому: не заводить таковых. Как? В функции Main создаются необходимые локальные переменные (обычно, одна-единственная). У неё вызывается какой-нить Run. Далее: все данные — это поля (не статические) этой переменной.

Соображение первое: Языки программирования могли бы позволять явно специфицировать функции/методы как не имеющие доступа к глобальным переменным, и таким образом помочь описанному выше стилю программирования:

int z;

int add(int x, int y) pure
{
    return x + z; // error
}

Соображение второе: Всегда есть возможность передавать эту локальную определенную в Main переменную в каждую функцию программы, причем этот подход наверняка будет кем-либо с гордостью использован, если Singleton вдруг станет не модным.

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

_FR>>Если по-простому: не заводить таковых. Как? В функции Main создаются необходимые локальные переменные (обычно, одна-единственная). У неё вызывается какой-нить Run. Далее: все данные — это поля (не статические) этой переменной.

I>Соображение первое: Языки программирования могли бы позволять явно специфицировать функции/методы как не имеющие доступа к глобальным переменным, и таким образом помочь описанному выше стилю программирования:

Зачем? достаточно выбрасить все ненужные глобальные переменные. А зачем они ещё нужны, если не для того, что бы ими кто-то пользовался.

I>Соображение второе: Всегда есть возможность передавать эту локальную определенную в Main переменную в каждую функцию программы, причем этот подход наверняка будет кем-либо с гордостью использован, если Singleton вдруг станет не модным.

Совсем ничего не понял

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

_FR>Это всё, думаю, тебе известно Ты какие-то конкретные трудности видишь?

Прозрачности нет. Постоянно нужно таскать с собой те переменные, которые непосредственно тебе могут и не понадобиться, а понадобятся тем классам, которые ты будешь создавать. ИМХО, это приводит к чрезмерной связности объектов. Нехорошо это.

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

_FR>Совсем ничего не понял

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

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

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>У меня в системе синглетоном ещё логгер реализован.

I>Чем это в твоем случае лучше чем статическими методами?

Тем, что синглтон реализован один раз генериком, а Logger — обычный класс, реализующий интерфейс.

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

_FR>>Совсем ничего не понял

I>Ну выбросит человек все глобальные переменные, определит в Main одну содержащую в себе значения всех этих бывших глобальных, добавит к каждой функции/методу в программе параметр типа этой новой переменной и будет передавать ее при каждом вызове.

Когда человек хочет прострелить себе ногу, изобретальность его достойна восхощения. Дело лишь в том, что отказавшись от глобальных переменных он не сможет стрельнуть случайно, для этого придётся совершить определённые действия, которые по ошибке совершить невозможно.

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

_FR>Зачем? достаточно выбрасить все ненужные глобальные переменные.

Если выбросить все ненужные, то возможно останутся нужные. А чистая функция не должна использовать никаких.

Впрочем возможно ты имел ввиду, что ни одна глобальная переменная не является нужной. Может быть (хотя я не был бы так категоричен), но в тех случаях, когда глобальные переменные уже есть в системе, от них часто проще избавляться по частям; а в тех случаях, когда они есть в используемой библиотеке, от них и вовсе не избавиться.

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

AS>Тем, что синглтон реализован один раз генериком, а Logger — обычный класс, реализующий интерфейс.

А зачем нужен этот интерфейс?

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

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Тем, что синглтон реализован один раз генериком, а Logger — обычный класс, реализующий интерфейс.

I>А зачем нужен этот интерфейс?

Всего лишь для того, чтобы не зависеть от конкретной реализации логгера. В данный момент я использую log4net в качестве бэка. Когда найду что-нибудь лучше — мне надо будет всего лишь заменить реализацию.

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

AS>Всего лишь для того, чтобы не зависеть от конкретной реализации логгера. В данный момент я использую log4net в качестве бэка. Когда найду что-нибудь лучше — мне надо будет всего лишь заменить реализацию.

Ну а в случае статического класса кто то же самое сделать мешает?

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

_FR>>Это всё, думаю, тебе известно Ты какие-то конкретные трудности видишь?

L>Прозрачности нет. Постоянно нужно таскать с собой те переменные, которые непосредственно тебе могут и не понадобиться, а понадобятся тем классам, которые ты будешь создавать.

Наоборот, получается, что всё прозрачно: каждый уровень видит, что нужно связанным с ним. А прозрачность (кажущаяся) — это как раз к синглетонам — фиг знает, что там в них используется.
И чрезмерная такая прозрачность — да, плохо. Небольшая — часто не мешает и даже наоборот.

Таскать, обычно, нужно одну переменную Application (в простом случае) или Container\Builder, через которую можно получить всё остальное. Второй приём — многие "синглетоны" заменятся обычными классами, которые можно на каждый чих (на каждую логический чих) создавать заново. Просто некоторые "оптимизаторы" думают — ага! для этого типа можно применить паттерн Синглетон! и всё будет здорово! тогда как наоборот, они могут отказаться от него и создавать нужные классы каждый раз по-требованию.

L>ИМХО, это приводит к чрезмерной связности объектов. Нехорошо это.

Не хорошо. Когда становится видно, что появилась "чрезмерная связанность", надо брать в руки IoC и таскать придётся один контейнер. Или, даже, не так. Если есть система объектов, то один знает про другой, другой про третий и т.д. тогда кто-то может и не иметь свой контейнер, а пользоваться контейнером какого-то объекта, про который он знает и у которого контейнер есть: получается не обяхательно везде его, контейнер, протаскивать.

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

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Всего лишь для того, чтобы не зависеть от конкретной реализации логгера. В данный момент я использую log4net в качестве бэка. Когда найду что-нибудь лучше — мне надо будет всего лишь заменить реализацию.

I>Ну а в случае статического класса кто то же самое сделать мешает?

Вероятно то, что мне не придётся "переписывать код", а "дописывать его".

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

AS>Вероятно то, что мне не придётся "переписывать код", а "дописывать его".

У тебя не только интерфейс, но и независимый от log4net абстрактный класс есть?

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

L>>Прозрачности нет. Постоянно нужно таскать с собой те переменные, которые непосредственно тебе могут и не понадобиться, а понадобятся тем классам, которые ты будешь создавать.

_FR>Наоборот, получается, что всё прозрачно: каждый уровень видит, что нужно связанным с ним. А прозрачность (кажущаяся) — это как раз к синглетонам — фиг знает, что там в них используется.
_FR>И чрезмерная такая прозрачность — да, плохо. Небольшая — часто не мешает и даже наоборот.

Я и не ратую за чрезмерное использование синглтонов. Один глобальный ServiceLocator — наш выбор.

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

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Вероятно то, что мне не придётся "переписывать код", а "дописывать его".

I>У тебя не только интерфейс, но и независимый от log4net абстрактный класс есть?

Есть. NullLogger. Шлёт всё в /dev/null.

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

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

_FR>>>Это всё, думаю, тебе известно Ты какие-то конкретные трудности видишь?

L>>Прозрачности нет. Постоянно нужно таскать с собой те переменные, которые непосредственно тебе могут и не понадобиться, а понадобятся тем классам, которые ты будешь создавать.

_FR>Наоборот, получается, что всё прозрачно: каждый уровень видит, что нужно связанным с ним. А прозрачность (кажущаяся) — это как раз к синглетонам — фиг знает, что там в них используется.
_FR>И чрезмерная такая прозрачность — да, плохо. Небольшая — часто не мешает и даже наоборот.

_FR>Таскать, обычно, нужно одну переменную Application (в простом случае) или Container\Builder, через которую можно получить всё остальное. Второй приём — многие "синглетоны" заменятся обычными классами, которые можно на каждый чих (на каждую логический чих) создавать заново. Просто некоторые "оптимизаторы" думают — ага! для этого типа можно применить паттерн Синглетон! и всё будет здорово! тогда как наоборот, они могут отказаться от него и создавать нужные классы каждый раз по-требованию.


А тут для этого используется контекст. И, вроде бы, совсем неплохо

здесь

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

_FR>Таскать, обычно, нужно одну переменную Application (в простом случае) или Container\Builder, через которую можно получить всё остальное.

IMHO таскать нужно только то, что нужно, а не все. "Container\Builder, через которую можно получить всё остальное" звучит устрашающе, и как я уже писал, для кого-то логическим завершением этой идей может стать передача Container\Builder-а каждому методу.

В общем, если все же приходится таскать все, глобальная переменная лучше.

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

AS>Есть. NullLogger. Шлёт всё в /dev/null.

Понятно. Тем не менее можно иметь и аналогичные методам NullLogger-а статические методы и использовать их при реализации методов зависимых от log4net. И тогда тоже придётся не "переписывать", а "дописывать".

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

EF>Народ подскжаите как в C# создать Singleton класс?

В свете развернувшейся дискуссии, рекомендую попробовать вот эту штуку. Будет полезна, очень.

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

D>В свете развернувшейся дискуссии, рекомендую попробовать вот эту штуку. Будет полезна, очень.

А ты вместо того, чтобы советовать, что лучше, а что нет, лучше присоединяйся к дисскусии.
Или ты тоже предлагаешь всюду за собой таскать контейнер?

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

L>А ты вместо того, чтобы советовать, что лучше, а что нет, лучше присоединяйся к дисскусии.
L>Или ты тоже предлагаешь всюду за собой таскать контейнер?

Если при разработке действительно возникает потребность в конструкциях по типу синглтона, то значит сложность софта вполне себе доросла до использования контейнера. И я предлагаю взять вполне конкретную вышеуказанную библиотеку. Она достаточно легковесная, а по части использования — проще и удобнее просто некуда.

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

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

L>>А ты вместо того, чтобы советовать, что лучше, а что нет, лучше присоединяйся к дисскусии.
L>>Или ты тоже предлагаешь всюду за собой таскать контейнер?

D>Если при разработке действительно возникает потребность в конструкциях по типу синглтона, то значит сложность софта вполне себе доросла до использования контейнера. И я предлагаю взять вполне конкретную вышеуказанную библиотеку. Она достаточно легковесная, а по части использования — проще и удобнее просто некуда.

Я не спорю, но в своей дипломной использовал ServiceLocator, например. Там 7 KLOC, вроде, было суммарно, уж не скажу точно. В enterprise проектах хорошо использовать IoC реализации. Но насчет указанной Вами не знаю... Рисковано пользовать вещи с сомнительной поддержкой или сырые. Чтобы потом не было

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

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Есть. NullLogger. Шлёт всё в /dev/null.

I>Понятно. Тем не менее можно иметь и аналогичные методам NullLogger-а статические методы и использовать их при реализации методов зависимых от log4net. И тогда тоже придётся не "переписывать", а "дописывать".

Сложно сделать это прозрачно для юзера логгера. Статические методы ведь не полиморфны.

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

D>Если при разработке действительно возникает потребность в конструкциях по типу синглтона, то значит сложность софта вполне себе доросла до использования контейнера.

Совершенно не факт. Большинство теперешних контейнеров штука весьма специфичная и для всего подряд не очень подходит. Так что вполне оправдано использование голого service locator безо всяких контейнеров.

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

AS>Сложно сделать это прозрачно для юзера логгера. Статические методы ведь не полиморфны.

Что значит сложно и зачем тебе здесь полиморфизм? Может быть пример в десять строчек приведешь?

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

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Сложно сделать это прозрачно для юзера логгера. Статические методы ведь не полиморфны.

I>Что значит сложно и зачем тебе здесь полиморфизм? Может быть пример в десять строчек приведешь?

Затем, чтобы юзер логгера не менял код логирования, если ему понадобится другой логгер, а только выбрал нужный в конфиге. Что тут непонятного?

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

EF>Народ подскжаите как в C# создать Singleton класс?

Ну например так.

public sealed class SingletonDemo
{
    private static readonly SingletonDemo _instance = new SingletonDemo();
    private SingletonDemo()
    {
    } 
    public static GetInstance
    {
        get
         {
             return _instance;
         }
    }
}

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

AVK>Здравствуйте, Pavel M., Вы писали:

PM>>1. Во-первых, ServiceLocator — паттерн, являющийся частью концепции EJB

AVK>Он используется в EJB, но точно так же используется и в куче других мест. И в BCL его реализация тоже есть.

Да? А где?

PM>> Не вижу больших минусов в использовании его в проектах малого-среднего размера.

AVK>Его это кого?

ServiceLocator вместо использования IoC реализаций, вроде Spring.NET, если в них до конца нет необходимости.

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

AVK>Большинство теперешних контейнеров штука весьма специфичная и для всего подряд не очень подходит.

Вот именно поэтому я веду речь о вполне конкретном контейнере. А не о монстроидальных убожествах типа Castle, или там Unity. Их вот, лично я, вообще никуда и никогда не возьму

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

L>Здравствуйте, Pavel M., Вы писали:

AVK>>>Он используется в EJB, но точно так же используется и в куче других мест. И в BCL его реализация тоже есть.

PM>>Да? А где?

L>IServiceProvider, IServiceContainer, ServiceContainer

На самом деле там реализация простейшая и совсем не Singleton, так что разве что оттуда полезное, что интерфейс из стандартной библиотеки.

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

D>Вот именно поэтому я веду речь о вполне конкретном контейнере. А не о монстроидальных убожествах типа Castle, или там Unity. Их вот, лично я, вообще никуда и никогда не возьму

А потом придется в чужом коде вылавливать баги. К сомнительным проектам нужно осторожнее относиться. "Монстры" чаще обновляются и фиксятся.

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

L>Я и не ратую за чрезмерное использование синглтонов. Один глобальный ServiceLocator — наш выбор.

А теперь посмотри, например, на Component Model во фреймворке (классы из System.ComponentModel). В многих их методах требуется IServiceProvider, но синглетона нигде нет, и все обходятся без него и не знаю ни одного примера, где бы это мешало. Всё дело в грамотном проектировании: есть IComponent, в котором есть Site (ISite: наследник IServiceProvider).

Site ни одному компоненту (из известных мне) ещё не помешал. Когда же требуется, он заботливо выставляется environment-ом и предоставляет доступ ко всему. А почти всё, что крутится вокруг обработки компонентов имеет доступ к какому-либо компоненту и, следовательно, к его сайту и сервисам. Там же, где компонентов в явном виде нет, в методы передаются _необходимые_ контексты (важно отметить, что контексты нужны независимо от того, есть у нас сервис-провайдер или нет), и какой-то ServiceProvider можно вытащить из такого контекста. Опять же проблем с тем, что "приходится что-то ненужное таскать повсюду" нет: всегда приходится что-то да таскать, передавать данные из одного кода в другой. Часть таких данных и мождно сделать IServiceProvider или любой другой контейнер. Даже то, что зачастую в методы передаётся "голый" IServiceProvider всё-таки не порит какртину, по крайней мере, никакого удивления\неприятия у мен оно не вызывало.

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

L>Я и не ратую за чрезмерное использование синглтонов. Один глобальный ServiceLocator — наш выбор.

Кстати, у вас же ASP, если не ошибаюсь: чем определяются границы "глобальности": доменом или чем-то ещё?

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

PM>На самом деле там реализация простейшая

Глядя на CommonServiceLocator, приходится признать, что это скорее плюс, чем минус.

PM> и совсем не Singleton

И слава богу. В BCL вообще немного синглтонов, особенно неувязанных с TLS.

PM>, так что разве что оттуда полезное, что интерфейс из стандартной библиотеки.

На базе этого интерфейса даже в самой BCL довольно много построено (в основном в System.ComponentModel)

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

D>Вот именно поэтому я веду речь о вполне конкретном контейнере.

Какой бы он не был конкретный, все одно его надо применять, если нужен именно контейнер, а не реализация service locator.

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

AS>Затем, чтобы юзер логгера не менял код логирования, если ему понадобится другой логгер, а только выбрал нужный в конфиге.

OK, это аргумент. Правда не сказать, что решение дать пользователю возможность в конфигурационном файле задавать используемую библиотеку протоколирования является особо ортодоксальным.

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

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Затем, чтобы юзер логгера не менял код логирования, если ему понадобится другой логгер, а только выбрал нужный в конфиге.

I>OK, это аргумент. Правда не сказать, что решение дать пользователю возможность в конфигурационном файле задавать используемую библиотеку протоколирования является особо ортодоксальным.


Это не user-scope настройка => при нормальной системе администрирования доступ к этой настройке имеет только системный администратор заказчика.

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

AS>Это не user-scope настройка => при нормальной системе администрирования доступ к этой настройке имеет только системный администратор заказчика.

Тем не менее и решение дать администратору возможность в конфигурационном файле задавать используемую библиотеку протоколирования несколько необычно.

AVK>>Большинство теперешних контейнеров штука весьма специфичная и для всего подряд не очень подходит.
D>Вот именно поэтому я веду речь о вполне конкретном контейнере. А не о монстроидальных убожествах типа Castle, или там Unity. Их вот, лично я, вообще никуда и никогда не возьму
Написали бы лучше сравнение Unity c Autofac. Был гораздо белее интресный аргумент.

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

L>>Я и не ратую за чрезмерное использование синглтонов. Один глобальный ServiceLocator — наш выбор.

_FR>Кстати, у вас же ASP, если не ошибаюсь: чем определяются границы "глобальности": доменом или чем-то ещё?

Риквестом.

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

_FR>Site ни одному компоненту (из известных мне) ещё не помешал. Когда же требуется, он заботливо выставляется environment-ом и предоставляет доступ ко всему. А почти всё, что крутится вокруг обработки компонентов имеет доступ к какому-либо компоненту и, следовательно, к его сайту и сервисам. Там же, где компонентов в явном виде нет, в методы передаются _необходимые_ контексты (важно отметить, что контексты нужны независимо от того, есть у нас сервис-провайдер или нет), и какой-то ServiceProvider можно вытащить из такого контекста. Опять же проблем с тем, что "приходится что-то ненужное таскать повсюду" нет: всегда приходится что-то да таскать, передавать данные из одного кода в другой. Часть таких данных и мождно сделать IServiceProvider или любой другой контейнер. Даже то, что зачастую в методы передаётся "голый" IServiceProvider всё-таки не порит какртину, по крайней мере, никакого удивления\неприятия у мен оно не вызывало.

Меня больше интетесует использование ServiceProvider-ов в объектной модели предметной области. Как поступать там? Тащить в каждую сущность ссылку на сервис-провайдер?

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

L>Меня больше интетесует использование ServiceProvider-ов в объектной модели предметной области. Как поступать там? Тащить в каждую сущность ссылку на сервис-провайдер?

Это, как понимаешь, зависит от того, что и как в предметной области уже сделано. Есть ли какой-то контекст, в котором живут объекты, какой-то коренной объект, из которого они получаются? Что из себя представляют объекты предметной области: наследники какого-то толстого объекта или наоборот, аналоги кортежей с полями, но без логики, которая реализована в отдельных сервисах? Вариантов тьма. Приведи пример, где не получается обойтись без синглетона (или где не красиво\сложно без него) — тогда будет интереснее :о)

Объединяя с предыдущим вопросом:

_FR>>Кстати, у вас же ASP, если не ошибаюсь: чем определяются границы "глобальности": доменом или чем-то ещё?
L>Риквестом.

То есть, на каждый реквест заново создаётся локатор, и в него подгружаются (создаются заново или откуда-то бурутся) все сервисы?

Здравствуйте, _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>();

?

Здравствуйте, _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>Недостатки этого варианта я вижу, а вот достоинств как-то не наблюдается.

Какие? Не зная подноготной (например, на сколько дорого создание сервисов), я недостатков не вижу А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.

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

L>>Если методу класса понабиться например проверить права, то какая разница откуда получать ссылку на SecurityProvider — из объектной модели или из сервисных классов?

_FR>Только та, что в данный момент у тебя для сервисных классов заведён синглетон, от которого ты не наешь, как избавиться.

Я? Ты меня с кем-то путаешь. У меня заведен один сервис-провайдер, доступ к которому — через синглтон. И избавляться от него у меня нет никакого желания.

_FR>>>А что бы тогда повсюду, где нужно, вместо
_FR>>>не делать так:

L>>Недостатки этого варианта я вижу, а вот достоинств как-то не наблюдается.

_FR>Какие? Не зная подноготной (например, на сколько дорого создание сервисов), я недостатков не вижу

А они есть. Как ты в твоем варианте тестирование организуешь?
Если у тебя единственный сервис-контейнер, то просто в начале теста засовываешь в него моки нужных сервисов и запскаешь тест.
А что делать, если создание контейнеров разбросано всюду?

_FR>А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.

Почему отсутствие синглтона является преимуществом?

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

L>>>Если методу класса понабиться например проверить права, то какая разница откуда получать ссылку на SecurityProvider — из объектной модели или из сервисных классов?
_FR>>Только та, что в данный момент у тебя для сервисных классов заведён синглетон, от которого ты не наешь, как избавиться.
L>Я? Ты меня с кем-то путаешь. У меня заведен один сервис-провайдер, доступ к которому — через синглтон. И избавляться от него у меня нет никакого желания.

"Не хочешь" и "не знаешь" — разные вещи. Я вижу, что "не хочешь", а судя по этому

Автор: Lloyd
Дата: 17.10.08

сообщению, сделал вывод, что наверняка "не знаешь".

_FR>>>>А что бы тогда повсюду, где нужно, вместо
_FR>>>>не делать так:
L>>>Недостатки этого варианта я вижу, а вот достоинств как-то не наблюдается.
_FR>>Какие? Не зная подноготной (например, на сколько дорого создание сервисов), я недостатков не вижу

L>А они есть. Как ты в твоем варианте тестирование организуешь?
L>Если у тебя единственный сервис-контейнер, то просто в начале теста засовываешь в него моки нужных сервисов и запскаешь тест.

Да

L>А что делать, если создание контейнеров разбросано всюду?

Зачем несколько контейнеров? Ну даже если и нужны, то контейнер нужно создавать через фабрику, которая данные читает из конфига. Хоть сотнями создавай, разницы никакой

_FR>>А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.

L>Почему отсутствие синглтона является преимуществом?

Вопрос тут не раз задавался и обсуждений много. Если ты считаешь наличие синглетона преимуществом, спорить не буду, потому что не хочу, но мы сейчас обсуждаем не достоинства \недостатки синглетонов, а то, как от синглетона можно избавиться.

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

_FR>Зачем несколько контейнеров? Ну даже если и нужны, то контейнер нужно создавать через фабрику, которая данные читает из конфига. Хоть сотнями создавай, разницы никакой

_FR>>>А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.

L>>Почему отсутствие синглтона является преимуществом?

_FR>Вопрос тут не раз задавался и обсуждений много. Если ты считаешь наличие синглетона преимуществом, спорить не буду, потому что не хочу, но мы сейчас обсуждаем не достоинства \недостатки синглетонов, а то, как от синглетона можно избавиться.

Вот у тебя значок "эксперт" Поясни, пожалуйста, чем синглтон так плох? Я пока не вижу в нём проблем, если применять по месту.

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

L>>>>Если методу класса понабиться например проверить права, то какая разница откуда получать ссылку на SecurityProvider — из объектной модели или из сервисных классов?
_FR>>>Только та, что в данный момент у тебя для сервисных классов заведён синглетон, от которого ты не наешь, как избавиться.
L>>Я? Ты меня с кем-то путаешь. У меня заведен один сервис-провайдер, доступ к которому — через синглтон. И избавляться от него у меня нет никакого желания.

_FR>"Не хочешь" и "не знаешь" — разные вещи. Я вижу, что "не хочешь", а судя по этому

Автор: Lloyd
Дата: 17.10.08

сообщению, сделал вывод, что наверняка "не знаешь".

Если я не вижу выгод от избавления, то и знать не желаю, как от него избавляться.

L>>А они есть. Как ты в твоем варианте тестирование организуешь?
L>>Если у тебя единственный сервис-контейнер, то просто в начале теста засовываешь в него моки нужных сервисов и запскаешь тест.

_FR>Да

L>>А что делать, если создание контейнеров разбросано всюду?

_FR>Зачем несколько контейнеров?

Не "несколько контейнеров", а несколько мест, где нужно получить доступ к необходимым нам сервисам.

_FR>Ну даже если и нужны, то контейнер нужно создавать через фабрику, которая данные читает из конфига. Хоть сотнями создавай, разницы никакой

Конфиги — это не так удобно, как кажется. Через конфиг я моки в тестах не сконфигурю.

_FR>>>А подробности ты раскрыть и не можешь? тянуть у тебя по крупице как-то не интересно. А преимущества: есть локатор и нет синглетона.

L>>Почему отсутствие синглтона является преимуществом?

_FR>Вопрос тут не раз задавался и обсуждений много. Если ты считаешь наличие синглетона преимуществом, спорить не буду, потому что не хочу, но мы сейчас обсуждаем не достоинства \недостатки синглетонов, а то, как от синглетона можно избавиться.

Я этого не обсуждаю. Мне это не интересно.
Про недостатки синглтонов мне известно, обсуждения я эти читал. Да вот только обсуждалась ситуация, когда каждый сервис — синглтон. В моем случае синглтоном является не сервис, а сервис провайдер. Какие здесь недостатки я не вижу.

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

AS>Поясни, пожалуйста, чем синглтон так плох? Я пока не вижу в нём проблем, если применять по месту.

1. Прежде, чем спрашивать... (намекаю на поиск)
   
2. В соответствующий форум

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

AVK>Какой бы он не был конкретный, все одно его надо применять,

Я рекомендую Вам всё-таки посмотреть его сначала. Он крайне прост и удобен в применении, и именно поэтому я не вижу противопоказаний к его использованию.