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

Tom>·>Service Locator.
Tom>Так не надо его использовать. Контейнер то тут причём
Ещё как причём. Открываешь первую попавшуюся доку по контенерам и там этим всё пестрит, как будто так и надо.
И ты вот уже неосознанно используешь "константу как при регистарции так и при резолве". Регистация и резолв это и есть SL. Т.е. ты регистируешь в реестре инстанс по ключу "тип" или "тип+простая_строка", потом его достаёшь:

container.Register<IFoo, Foo>();
var instance = container.GetInstance<IFoo>();

Для DI не нужны никакие регистрации и резолвы.

Tom>Конечно есть некоторые исключения — вершина стека вызовов. Аля новый поток но тут ничего не сделать.
Не нужны никакие исключения.

public static void main(args)
{
  var app = new AppModule();
  app.run(args);
}

Tom>Мне казалось я понятно обьяснил зачем нужны строки.
Ты объяснил для чего ты их используешь, но не объяснил зачем ты используешь именно строки, а не миллион других способов выразить полиморфизм.

Tom>1-е для того что бы сказать контейнеру что он не должен переопределять зависимость а должен зарегистрировать вторую для того жде интерфейса.
Зачем зарегистрировать-то?? С какой целью?

Tom>2-й для того что бы как то можно было зарезолвить зависимость по имени. Таких случаев тьма, случаи когда есть N обьектов реализующих один и тот же интерфейс, как пример ICommand. И никаких проблем строки не создают, обьявите их константами и используйте.
Почему именно по строковому имени? А если у меня long-идентификатор? или тупо bool? Потому что контейнер по-другому не умеет. Да ведь?
Если тебе так надо, то так и напиши: Map<String, IFoo>, или switch-case, или if. Вон сколько есть выразительных средств, а ты вынужден использовать только строки, т.к. даже самый современный контейнер по-другому особо и не умеет.

Tom>>>Ничего не понимаю что куда залетело. В общем случае фича которая называется auto wire работает прекрасно. Регистрируешь только то что отличается от принятых в контейнере конвенций.
Tom>·>Я о http://www.lightinject.net/#assembly-scanning , а ты о чём?
Tom>И я о том же, обычно это называется auto wiring
Нет. Почитай доки что-ли для начала. Если непонятно, могу объяснить.

Tom>·>Циклические зависимости делать не надо. Никогда. А если это действительно неизбежно — это должно быть сложно и сразу явно видно. Ты можешь случайно добавить незаметив, а контейнер тебе всё сам свяжет и не пикнет, втихую добавив +100 к техническому долгу. А потом эту вязанку развязывать.
Tom>Да действительно контейнер в случае циклической зависимости упадёт только во время резолва. У меня такая проблема встречалась один раз и выявлена была в тестах. Ничего серьёзного, решилась за пару часов.
В случае использования lazy и property injection этот самый auto-wiring всё втихую сошьёт.

Tom>·>public class RequestModule и пусть он и управляет временем жизни создаваемых им IDisposable-ы ровно так как надо, а не универсальный всемогутер, который делает какую-то неявную магию.
Tom>Не понял я кто такой RequestModule и как он может определить какой обьект надо диспоузить а какой нет.
RequestModule это контекст создаваемый для реквеста. В нём и будет нужные new внутри using. Он не должен ничего определять, ты сам пишешь код так, чтобы всё что надо диспозилось когда надо.

Tom>·>Я знаю. Сам таким был.
Tom>·>Потом попал в компанию, где история развития была такая: "что попало как попало" -> "монстр Spring Framework" -> "модный Guice" -> "DI, plain Java code". По началу тоже возмущался отстутсвием "современного" контейнера, а потом осенило.
Tom>Я кстате заметил что ты из жабы+spring пришёл по опасениям за конфиг+xml.
Tom>Сейчас контейнеры совсем лругие. Это уже не монстры а достаточно простые, быстрые и логичные девайсы.
Tom>Советую перестать их бояться, хотя бы попробовать не нескольких проектах.
Tom>Многое становиться делать проще и удобнее чем руками.
guice именно такой, там вообще нет xml-конфигов. Но всё равно фтопку.
spring4 тоже теперь умеет xml-free.

Tom>Ничего контейнер не прячем, зависимости у каждого класса явные. Если их много, то эта проблема и так явная и контейнер тут не причём.
Я говорю не о классе, а о крупных модулях/блоках приложения.

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

Tom>·>Service Locator.
Tom>Так не надо его использовать. Контейнер то тут причём
Ещё как причём. Открываешь первую попавшуюся доку по контейнерам и там этим всё пестрит, как будто так и надо.
И ты вот уже неосознанно используешь "константу как при регистарции так и при резолве". Регистация и резолв это и есть SL. Т.е. ты регистируешь в реестре инстанс по ключу "тип" или "тип+простая_строка", потом его достаёшь:

container.Register<IFoo, Foo>();
var instance = container.GetInstance<IFoo>();

Для DI не нужны никакие регистрации и резолвы.

Tom>Конечно есть некоторые исключения — вершина стека вызовов. Аля новый поток но тут ничего не сделать.
Не нужны никакие исключения.

public static void main(args)
{
  var app = new AppModule();
  app.run(args);
}

Tom>Мне казалось я понятно обьяснил зачем нужны строки.
Ты объяснил для чего ты их используешь, но не объяснил зачем ты используешь именно строки, а не миллион других способов выразить полиморфизм.

Tom>1-е для того что бы сказать контейнеру что он не должен переопределять зависимость а должен зарегистрировать вторую для того жде интерфейса.
Зачем зарегистрировать-то?? С какой целью?

Tom>2-й для того что бы как то можно было зарезолвить зависимость по имени. Таких случаев тьма, случаи когда есть N обьектов реализующих один и тот же интерфейс, как пример ICommand. И никаких проблем строки не создают, обьявите их константами и используйте.
Почему именно по строковому имени? А если у меня long-идентификатор? или тупо bool? Потому что контейнер по-другому не умеет. Да ведь?
Если тебе так надо, то так и напиши: Map<String, IFoo>, или switch-case, или if. Вон сколько есть выразительных средств, а ты вынужден использовать только строки, т.к. даже самый современный контейнер по-другому особо и не умеет.

Tom>>>Ничего не понимаю что куда залетело. В общем случае фича которая называется auto wire работает прекрасно. Регистрируешь только то что отличается от принятых в контейнере конвенций.
Tom>·>Я о http://www.lightinject.net/#assembly-scanning , а ты о чём?
Tom>И я о том же, обычно это называется auto wiring
Нет. Почитай доки что-ли для начала. Если непонятно, могу объяснить.

Tom>·>Циклические зависимости делать не надо. Никогда. А если это действительно неизбежно — это должно быть сложно и сразу явно видно. Ты можешь случайно добавить незаметив, а контейнер тебе всё сам свяжет и не пикнет, втихую добавив +100 к техническому долгу. А потом эту вязанку развязывать.
Tom>Да действительно контейнер в случае циклической зависимости упадёт только во время резолва. У меня такая проблема встречалась один раз и выявлена была в тестах. Ничего серьёзного, решилась за пару часов.
В случае использования lazy и property injection этот самый auto-wiring всё втихую сошьёт.

Tom>·>public class RequestModule и пусть он и управляет временем жизни создаваемых им IDisposable-ы ровно так как надо, а не универсальный всемогутер, который делает какую-то неявную магию.
Tom>Не понял я кто такой RequestModule и как он может определить какой обьект надо диспоузить а какой нет.
RequestModule это контекст создаваемый для реквеста. В нём и будет нужные new внутри using. Он не должен ничего определять, ты сам пишешь код так, чтобы всё что надо диспозилось когда надо.

Tom>·>Я знаю. Сам таким был.
Tom>·>Потом попал в компанию, где история развития была такая: "что попало как попало" -> "монстр Spring Framework" -> "модный Guice" -> "DI, plain Java code". По началу тоже возмущался отстутсвием "современного" контейнера, а потом осенило.
Tom>Я кстате заметил что ты из жабы+spring пришёл по опасениям за конфиг+xml.
Tom>Сейчас контейнеры совсем лругие. Это уже не монстры а достаточно простые, быстрые и логичные девайсы.
Tom>Советую перестать их бояться, хотя бы попробовать не нескольких проектах.
Tom>Многое становиться делать проще и удобнее чем руками.
guice именно такой, там вообще нет xml-конфигов. Но всё равно фтопку.
spring4 тоже теперь умеет xml-free.

Tom>Ничего контейнер не прячем, зависимости у каждого класса явные. Если их много, то эта проблема и так явная и контейнер тут не причём.
Я говорю не о классе, а о крупных модулях/блоках приложения.