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

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

Tom>>единственный кошерный способ это использование IoC & DI принципов

MC>Только у меня неприятие IoC-контейнеров? Мне кажется это какая-то мода, которая создаёт свои проблемы и без чего можно прекрасно обойтись. Особо меня пугает, что в некоторых книгах (например Pro ASP.NET MVC 4 by Adam Freeman (в целом книга неплохая)) применение IoC-контейнеров идет по умолчанию и преподносится как что-то само собой разумеещееся. Со мной что-то не так и мне надо лучше вникать в IoC-контейнеры или всё нормально? Хотелось бы мнения уважаемых опытных разработчиков.

С тобой всё абсолютно так. Это нормальная ПЕРВАЯ реакция.
Понимание этих принципов идёт через понимание проблем которые они призваны решать.
Вообще я не видел ещё ни одного девелопера который бы сразу проникса этой идеей.
Просветление наступает по поим наблюдениям от полу года до пары лет.
Причём чем младше девелопер тем проще ему перестраиваться.
Некоторые никогда не перестраиваются.

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

Tom>Давай на конкретных примерах.

Ага, и сразу сериальный порт. А где же DateTime.Now?

Tom>Накидал простейший пример, думаю коментарии не нужны.
Tom>Перереши его так как считаешь нужным:

Блин, ну вы как дети малые

IEnumerable<Message> Process(MessageParser parser, IEnumerable<byte> sequence)
{
    var message = new List<byte>();

    foreach (var b in sequence)
    {
        message.Add(b);

        if (parser.IsEom(b))
            yield return parser.Parse(message);
    }
}

И прошу заметить, не понадобилось ни одного кастомного интерфейса.

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

Никого не слушай. У DI весьма специфическое реальное применение — в плагинных архитектурах и приложения, которые к моменту своего выполнения понятия не имеют чего они там будут выполнять. Остальное — overdesign. DI для тестов это очень чёткий и вполне одназначный признак такой архитектуры.

А судя по нашим оппонентам на этом форуме, у меня складывается впечатление, что DI — это ещё и ловушка для ума, эдакая петля захвата. Если в неё попадает неокрепший ум, то выбраться из неё крайне сложно, потому что у таких умов возникает чувство собственной просветлённости, хотя по сути речь идёт о косвенном вызове метода. В результате получаются люди с искалеченной DI'ем судьбой

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

IT>А это первый признак зашоренности мышления, идолопоклонничества и восприятия мира через замочную скважину. Открой двери, станет лучше видно. ОО здесь вообще по боку.

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

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

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

Tom>>Если в тестах надо эмулировать их поведение то единственный кошерный способ это использование IoC & DI принципов

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

повторюсь.
как без глобального контекста (httpcontext) обойтись в asp.net mvc?

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

IT>Конечно, когда надо поддерживать проект с говнокодом, то мигом незашоренные люди смываются с проекта, ибо даже они не собираются разбираться в том, что накодили. Конечно ОО по боку, если плевать на чем писать, то явно получится говнокод очередного незашоренного человека.

Ты это о ком?

Здравствуйте, Аноним, Вы писали:

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

А>повторюсь.
А>как без глобального контекста (httpcontext) обойтись в asp.net mvc?

Для чего он конкретно нужен в конкретном asp.net mvc проекте?

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

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

Tom>>Если в тестах надо эмулировать их поведение то единственный кошерный способ это использование IoC & DI принципов

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

а можно статью или книгу где есть примеры как сделано с чистыми функциями и как тоже самое сделано с di?

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

IT>Здравствуйте, Аноним, Вы писали:

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

А>>повторюсь.
А>>как без глобального контекста (httpcontext) обойтись в asp.net mvc?

IT>Для чего он конкретно нужен в конкретном asp.net mvc проекте?

из него берется данные о юзере. Своя реализация от IIdentity

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

MC>Только у меня неприятие IoC-контейнеров?
Не только. IOC/DI — вполне хорошая штука, если использовать их по делу. Проблема в том, что у любой технологии есть свой порог сложности — затраты на изучение, внедрение в код, наработка лучших практик для конкретного проекта и т.д и т.п.. Если сложность решаемой задачи ниже порога сложности какой-либо технологии, то применять эту технологию очевидно бессмысленно. Ну, как привлекать боинг для развозки газет — для рекламы может и можно, но соседи будут точно недовольны

Поэтому набор удачных сценариев использования для IoC очень ограничен. Классический пример — расширяемость студии до перехода на MEF (до 2010й студии) и после.

MC>Мне кажется это какая-то мода, которая создаёт свои проблемы и без чего можно прекрасно обойтись.
Угу. Надо же на что-то переключаться после smart client/паттернов/экстремального программирования/веб-сервисов/noSQL/MVC/...

IT>И прошу заметить, не понадобилось ни одного кастомного интерфейса.
Эээ так у тебя пример не полный.
Где сам девайс в твоём примере то?

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

IT>>И прошу заметить, не понадобилось ни одного кастомного интерфейса.
Tom>Эээ так у тебя пример не полный.
Tom>Где сам девайс в твоём примере то?
Да и обработчика сообщений я у тебя не вижу.
Перепиши пример полностью плиз.

PS:
У нас вроде была возможность редактировать сообщения когда то?

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

IT>А судя по нашим оппонентам на этом форуме, у меня складывается впечатление, что DI — это ещё и ловушка для ума, эдакая петля захвата. Если в неё попадает неокрепший ум, то выбраться из неё крайне сложно, потому что у таких умов возникает чувство собственной просветлённости, хотя по сути речь идёт о косвенном вызове метода. В результате получаются люди с искалеченной DI'ем судьбой

не надо путать DI и IoC, не смотря на то, что они парами ходят — это вообще две разные вещи. Inversion of control — это проекция SOA принципов построения программных систем на современные фреймворки, что само по себе достаточно фундаментально и существует не первый десяток лет. А dependency injection — это особенность реализации большинства современных контейнеров, она получила широкое распространение всего пару лет назад и действительно является злом, т.к. control flow становится очень сильно не очевидным и соответственно слабоподдерживаемым.

Здравствуйте, Visor2004, Вы писали:
V>control flow становится очень сильно не очевидным и соответственно слабоподдерживаемым.

Это вы про Service Locator?

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

V>не надо путать DI и IoC, не смотря на то, что они парами ходят — это вообще две разные вещи.

Угу. Так уж сложилось, что DI/IoC используют как синоним для фреймворка, реализующего этот паттерн. По крайней мере, упоминание IoC в контексте "просто передаём нужный интерфейс (класс) через параметры" мне практически не попадалось.

Здравствуйте, Аноним, Вы писали:

А>а можно статью или книгу где есть примеры как сделано с чистыми функциями и как тоже самое сделано с di?

Поищите где-нибудь в интернете.

Здравствуйте, Аноним, Вы писали:

А>>>как без глобального контекста (httpcontext) обойтись в asp.net mvc?
IT>>Для чего он конкретно нужен в конкретном asp.net mvc проекте?
А>из него берется данные о юзере. Своя реализация от IIdentity

Большинство вещей связанных с авторизацией делаются атрибутами, поэтому прямой доступ к контексту не нужен. Если же непосредственный доступ к Identity необходим, то у контроллера есть вполне доступное нестатическое свойство User.

Но дело даже не в этом. Наличие статического контекста как такового не означает, что раз он есть и ниспослан нам свыше Майкрософтом, то это есть благо и его надо пихать куда только можно. Всегда можно локализовать подобную заразу и ограничить её распространение. Всего лишь не надо использовать такой контекст глубоко в классах бизнес логики. Можно передать необходимые данные в качестве параметров.

В .NET есть очень простой способ убедиться в том, что разрабатываемый компонент самодостаточен, независим и слабосвязан с другими частями системы. Такой компонент можно оформить в виде отдельной сборки и тщательно следить за недопущением в её референсы как всяких System.Web, так и собственных не относящихся к делу сборок. Попробуйте. Поначалу будет сложно обходиться без статики, но со временем к статическому контексту выработается устойчивое отвращение.

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

IT>>И прошу заметить, не понадобилось ни одного кастомного интерфейса.
Tom>Эээ так у тебя пример не полный.
Tom>Где сам девайс в твоём примере то?

Возьми свой и прикрути к нему энумератор. Научить как это делается?

Кстати, я не знаю как ты собираешься тестировать свой код с бесконечным циклом. Как будешь прерывать его выполнение, с помощью AbortException? Мой код тестировать элементарно, не нужно даже фейковые объекты создавать, просто передать в качестве входной последовательности тестовый массив байт. Результат тоже проверить элементарно и тоже без фековых объектов.

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

Tom>Да и обработчика сообщений я у тебя не вижу.
Tom>Перепиши пример полностью плиз.

Ну тогда давай и ты напиши свой пример полностью. Как минимум в нём нехватает то, а чём идёт спор — тестового метода.

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

V>не надо путать DI и IoC,

В каком конкретном месте я напутал?

V>А dependency injection — это особенность реализации большинства современных контейнеров, она получила широкое распространение всего пару лет назад и действительно является злом, т.к. control flow становится очень сильно не очевидным и соответственно слабоподдерживаемым.

Это ты расскажи апологетам DI. Для них DI это всё, что передаётся объекту в параметрах конструктора или через свойства. Потому что они не передают параметры, а инжектять зависимости.