Здравствуйте, 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 безо всяких контейнеров.

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

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

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

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

Его это кого?

Здравствуйте, 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, если в них до конца нет необходимости.

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

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

PM>Да? А где?

IServiceProvider, IServiceContainer, ServiceContainer

Здравствуйте, 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. Был гораздо белее интресный аргумент.