Паганель опять жжет... )

Где-то в степиvinnipuk,
банальная технология, исполнения кода по требованию, в некоторых случаях возвращение void в di что то другое.
что инжектировать - контекст запроса, переменные роутинга, контекст к хранилищам, может и есть проекты где это не заменимо и удобно, мне не встречались, имхо сама зарядка контейнера уже усложнение, тем более через конфиг
Соглашусь. Следовать самому принципу инферсии IoC для уменьшения связности кода - правильно и единственно верно (но тут тоже не нужно перегибать палку с интерфейсами). А уж какую реализацию IoC в виде инжектирования использовать - второстепенное, многим это вообще не нужно, особенно это касается времени управлению жизни и подобном фишкам DI контейнеров. Но и всегда есть альтернативы, которые можно заложить в свой подход IoC: паттерны Factory Method и Service Locator. В любом случае как инжектировать - это второстепенная задача, главное, чтобы можно было это сделать. А для этого нужно следовать принципам IoC.

SeVaevgen12345МСУ,
более чем согласен - большому числу проектов это не надо, а только снизит производительность.

А я не соглашусь.
DI не нужен, если:

- проект небольшой
- нет коллективной разработки
- не требуются дальнейшая поддержка и развитие.

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

Не вижу корреляции DI с размером проекта, коллективностью разработки и планами на поддержку и развитие. И что самое главное, ни слова о TDD.

skyANAМСУНе вижу корреляции DI с размером проекта, коллективностью разработки и планами на поддержку и развитие.ИМХО надо говорить не конкретно о DI, а об инверсии управления (Inversion of Control). Если этот принцип не применяется, то чем больше проект, тем в больших местах придётся вносить изменения при развитии последнего.
Именно об этом я и говорил тут 14296918 А наличие конкретного DI в проекте - второспепенный фактор, который одним нужен, другим не нужен.

evgen12345SeVa
Будьте добры - опишите ваш опыт - хотелось бы понять может я действительно не прав.
Это же Сева, наш фееричный параноик Нет у него никакого опыта, это все знают. Ходить по форумам, нести всякую чушь и брызгать слюной - вот его хобби.

skyANAЗамечу, что evgen12345 сказал, что придерживаться этого принципа не нужно в большинстве проектов.
Где?

skyANAМСУпропущено...

Где?Ну ты рассуждал про IoC, а evgen12345 согласился с тобой, что это не надо: 14297971 , - забавно получилось
Не надо ди, а не иок. Опять ты сеешь панику.

Где-то в степиskyANA,
трудно не согласиться, но при таки их обьемах точки входа девелопера, на первое место выходит не технологии которые используются, а документирование кода, что в прочем за свою куцею жизнь ( в размерах галактики) я не видел ни разу, хотя бы в средних обьемах, этими тоннами кода нужно управлять, тут не получится как сказал Лазарь Встань и иди Сядь и пиши, хотя сама реализация di контейнера банальна, при обилии из реализации лучше написать свой ( 10 15 минут) чем изучать изысканный
функционал существующих ( а может я и не прав), но в любом случае документирование кода выходит на первое место,
Эквилибристика ооп не знает границ, можно на ровном месте усложнить код так ( за пять минут) что стоны будут слышны неделями
например - изменение состояние объекта через его обработчик события или куда там еще можно спустить sender дальше по стеку..
Он соврал, потому что в природе не существует таких проектных команд. Максимум, 5-8 делелоперов, пара аналитиков, пара тестеров и пм на команду. А то я так могу и численность компании привести в неск. десятков тыс персон.

SeVaМСУпропущено...

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

Этим занимаешься исключительно ты, Гнидка. Для твоего порносайта и шизоида-одиночки всякие глупости в виде DI, естественно, не требуются

Ты глупое существо без ума и фантазии. Тебе задали вопрос, долго ты еще мычать будешь?

skyANAМСУпропущено...

Не надо ди, а не иок. Опять ты сеешь панику.Панику?

Я говорю, что забавно получилось:МСУА для этого нужно следовать принципам IoC.evgen12345МСУ,
более чем согласен - большому числу проектов это не надо, а только снизит производительность.
Ты выдрал из контекста. Он имел ввижу не надо DI :)

skyANAНука покажи, где я соврал?
Вот тут 14298881

skyANAПредполагаешь, что евген предлагает использовать фабрики и локаторы?
Ты в упор отказываешься понимать, что речь не о реализации или неумело троллишь? :)

skyANAМСУВот тут 14298881 Обоснуй.
Выше обосновал. Чтож ты такой невнимательный.

skyANAМСУ, не веришь, что основной солюшин содержит порядка 400-т проектов?
Мда, ты точно читаешь непонятно чем. Я тебе про команду (проектную, понятное дело).

SeVaСуществует ряд принципов(единичная ответственность;работаем не с частностями, а с общностями;разделение интерфейсов, те говносервис на все случаи жизни,горячо пропагандируемый MCУ, должен быть разбит на части; etc), которые желательно соблюдать, иначе возможны значительные трудности при дальнейшем развитии системы или при гибких методиках, когда необходимо постоянно шить, а затем пороть.
Чудило, ты скоро захлебнешься своей феерической теорией. Какая единичная ответственность, к чему этот унылый офтоп? Ты долго будешь тупить?

SeVaDI значительно упрощает их соблюдение, делает код чище.
Помимо этого весьма желательна модульность, MEF прекрасно для этого подходит(грузим модуль, он сам себя регистрирует в системе, есть возможность реагирования на изменения).
Разницу между IoC и DI понимаешь? Чем именно DI делает код чище? Очередной отжиг кухарки

SeVaПо началу, естественно, есть трудности с этим и возможные проблемы(если разработчик четко не понимает, что скрывается за интерфейсом, то он может сделать неоптимальную реализацию), но после 2-3х проектов все делается на автомате, а там где их нет, уже чувствуются тормоза при необходимости изменений или расширении.
Тормоза в твоей головке, а не в проектах. Пипец, срочно ветеринара!

skyANADI - это одна из реализаций принципа IoC (помимо этого есть еще Factory и Service Locator).
Да ладно?

skyANAТак о чём речь?
Речь о том, что IoC нужно, а DI - не обязательно. С этим и согласился evgen12345.

skyANA Считай . Как закончишь, то будь любезен, разверни свою мысль о том, что я лгу.
Я ж тебе уже писал, что я командой могу целую компанию из десятка тыс. сотрудников назвать. Речь о проектной команде. Или у вас сотрудники не делятся на проектные команды? Неверю (с)

skyANA, вот пример из методологии MSF: http://ru.wikipedia.org/wiki/Microsoft_Solutions_Framework

Модель проектной группы MSFВ соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться

Невозможно, как ни крути, управлять проектом из стада в полсотни рыл. Нужна детализация.