Я знаю про глобальный «inversion of control», столько же глобальный «dependency inversion principle», который не тоже самое что «dependency injection» и т.д.
Однако: «IoC в нынешнем применении»(с) = DI/IoC контейнер в 99% случаев.
Отсюда и уверенное утверждение, что не только для тестов.
Вы либо специально пытаетесь «передергивать», либо у нас не совпадает терминология.
DI CONTAINERS are also known as Inversion of Control (IoC) Containers or (more rarely) Lightweight Containers.
Mark Seeman
1) Вы выше написали, что IoC «в нынешнем применении»(с) необходим разве что для модульного тестирования.
2) Я вам написал, что ваша практика не равна всеобщей, приведя пример из своей, когда IoC применяется в основном не для тестирования, а для сборки графа объектов.
3) Вы пытаетесь бравировать схожими терминами IoC/DI, зачем-то вставляя слово «тривиальный».
Так что я склонаюсь к мнению, что вы специально «передергиваете», и дискуссия неконструктивна.
IoC в его нынешнем понимании и применении чаще всего необходим только для модульного тестирования.
Из практики, IoC контейнер нужен в основном для легкого пробрасывание зависимостей. Если классу нужна новая зависимость, то достаточно просто добавить ее интерфейс(или даже реализацию) в конструктор требуемого. И всё, ничего не надо переписывать, не надо протаскивать требуемый сервис по всей цепочке классов в n-мест, только для того чтобы использовать в создании требуемого.
А дмнамическая xml-конфигурация или статическая конфигурация(изменяемая) — да, баловство, очень редко требуется именно изменять. Здесь согласен. Ну и облегчение тестирования — некое следствие, да. Во главу угла ее, вероятно, ставить не стоит, иначе получится программа из 1000 классов в каждом из которых один метод из трех строк :) Хотя TDD именно как способ проектирования еще Макконел советовал, что-то в этом есть. Да и пропогандируемый дядей Бобом «extract Till you drop» брр.
Работа точно проделана не зря. Спасибо большое за расширение!
Жаль что с последней версией StyleCop перестало работать — приходится локально пересобирать из-за ошибки stylecopplus.codeplex.com/workitem/10424 но все равно всё супер.
Ужасный подход. Если на каждое требование заказчика «хреначить говнокод», чтобы «дешевле» — здесь никакой архитектуры (и по Фаулеру и без него) быть не может. Учитывая, что впоследствие на переделку денег также обычно никто давать не хочет. Сама архитектура приложения должна быть гибкая, чтобы просьба «добавить страницу партнеров» не вызывала у программистов чувство страха.
Если бы вы выложили информацию с именами и явками — больше бы и делать ничего не пришлось.
Так, если авиакомпания достаточно крупная, то этот пост бы не остался незамеченным.
А может быть SolBuilder вдобавок умеет профилировать процесс билда (показывать статистику по времени компиляции каждого проекта, на что ушло время)? :))
Дмитрий, а есть ли какая-нибудь killer-feature по сравнению с 7.1 для тех кто, кхм, не работает с CSS?
Ну, например, R# умеет optimize references, cleanup references… почему бы не уметь visualize references? Это я намекаю на то, что visual studio ultimate ценой ~500к это очень большая редкость и начинание интеграции с графом зависимостей 7й версии можно было бы продолжить и углубить =)
Нет, я ни в коем разе не прошу «фичу по заказу», просто после прочтения пре-релиза желания апгрейдится с 7.1 не возникло, т.к. изменений качественных, касаемых лично меня как разработчика, не заметил. Если, конечно, интересно мнение со стороны.
Самое интересное в вашем приложении — наблюдать на интерактивной карте как водитель едет к тебе на вызов и как он далеко на данный момент, на какой улице находится. :)
Супер, так держать!
К сожалению, в книге не описаны ChildContainers и зачем они нужны, это до сих пор загадка для меня :)
А так, книга просто шикарная. И глава 4 тоже не настолько плоха, она позволяет сложить поверхностное впечатление о существующих на рынке контейнерах.
Например, мне довелось использовать ORM-фреймворк, который не позволяет переопределять конструкторы вообще никак. Единственным вариантом здесь является сервис-локатор, который удалось привязать к Сессии и дергать через extension-метод получение сервисов. Получилось эдакое псевдо-property-injectrion, где локальная пропертя возвращает внешнюю зависимость, полученную через сервис-локатор.
хотя я сразу во втором комментарии описал, что я имею ввиду и что совершенно не собирался что-то критиковать. Просто неточность в статье.
Это не неточность а статье, это Java-style именование, где префикс I перед интерфейсом не принят. Данная мода в последнее время расползается и на .Net (привет Роберту Мартину и его CleanCode). :)
Либо Марк имел в виду абстрактный класс, но уж точно не конкретную реализацию.
Вы не называете, Марк Симанн же называет.
Вы спросили в чем может быть дискуссия, я вроде бы ответил. :)
Плюс действительно бывают случаи, когда без SL в бизнес-логике не обойтись.
Однако: «IoC в нынешнем применении»(с) = DI/IoC контейнер в 99% случаев.
Отсюда и уверенное утверждение, что не только для тестов.
Mark Seeman
1) Вы выше написали, что IoC «в нынешнем применении»(с) необходим разве что для модульного тестирования.
2) Я вам написал, что ваша практика не равна всеобщей, приведя пример из своей, когда IoC применяется в основном не для тестирования, а для сборки графа объектов.
3) Вы пытаетесь бравировать схожими терминами IoC/DI, зачем-то вставляя слово «тривиальный».
Так что я склонаюсь к мнению, что вы специально «передергиваете», и дискуссия неконструктивна.
Из практики, IoC контейнер нужен в основном для легкого пробрасывание зависимостей. Если классу нужна новая зависимость, то достаточно просто добавить ее интерфейс(или даже реализацию) в конструктор требуемого. И всё, ничего не надо переписывать, не надо протаскивать требуемый сервис по всей цепочке классов в n-мест, только для того чтобы использовать в создании требуемого.
А дмнамическая xml-конфигурация или статическая конфигурация(изменяемая) — да, баловство, очень редко требуется именно изменять. Здесь согласен. Ну и облегчение тестирования — некое следствие, да. Во главу угла ее, вероятно, ставить не стоит, иначе получится программа из 1000 классов в каждом из которых один метод из трех строк :) Хотя TDD именно как способ проектирования еще Макконел советовал, что-то в этом есть. Да и пропогандируемый дядей Бобом «extract Till you drop» брр.
Жаль что с последней версией StyleCop перестало работать — приходится локально пересобирать из-за ошибки
stylecopplus.codeplex.com/workitem/10424 но все равно всё супер.
Недавно проскочило во френдленте:
«Руководитель-наркоман» наше всё! :)
Не планируется ли перевод Art of Unit Testing-a в обозримое время www.manning.com/osherove/?
Так, если авиакомпания достаточно крупная, то этот пост бы не остался незамеченным.
А может быть SolBuilder вдобавок умеет профилировать процесс билда (показывать статистику по времени компиляции каждого проекта, на что ушло время)? :))
Ну, например, R# умеет optimize references, cleanup references… почему бы не уметь visualize references? Это я намекаю на то, что visual studio ultimate ценой ~500к это очень большая редкость и начинание интеграции с графом зависимостей 7й версии можно было бы продолжить и углубить =)
Нет, я ни в коем разе не прошу «фичу по заказу», просто после прочтения пре-релиза желания апгрейдится с 7.1 не возникло, т.к. изменений качественных, касаемых лично меня как разработчика, не заметил. Если, конечно, интересно мнение со стороны.
Супер, так держать!
А так, книга просто шикарная. И глава 4 тоже не настолько плоха, она позволяет сложить поверхностное впечатление о существующих на рынке контейнерах.
А можно мне ссылку? :)
Это не неточность а статье, это Java-style именование, где префикс I перед интерфейсом не принят. Данная мода в последнее время расползается и на .Net (привет Роберту Мартину и его CleanCode). :)
Либо Марк имел в виду абстрактный класс, но уж точно не конкретную реализацию.
Вы спросили в чем может быть дискуссия, я вроде бы ответил. :)
Плюс действительно бывают случаи, когда без SL в бизнес-логике не обойтись.
lair ниже все правильно написал.