Здравствуйте, Doc, Вы писали:
IT>>Кто тебе вообще сказал, что сервис должен быть изначально? Doc>Ага, т.е. сервис в том примере вообще лишний?
В каком примере?
IT>>Не надо путать божий дар с яичницей. Или тебе ообъяснить разницу между System.String и GetcustomerByID? Doc>Если GetcustomerByID проходит unit test — мне без разницы что внутри, до того момента, как будут основания это проверить.
Понятно. Разницы между библиотечной функцией общего назначения и логикой бизнес-приложения для тебя не существует.
Doc>Во, начни с себя и завязывай раздавать диагнозы
Опять начался детский сад. Судя по нашему предыдущему общению дальнейшая дискуссия с тобой начинает тепять всякий смысл. Пока.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT> I>Где меньше зависимостей ?
IT> Здесь:
IT>
IT> var n = MyVeryPrimitiveMethod(1, 2);
IT>
Я вот не могу понять это троллинг или что-то еще? Если 1 и 2 это константы то там DI делать нечего, но если эти значения приходят 'извне', то рано или поздно надо будет сделать getParam1 и getParam2. И там есть вероятность, что DI пригодится.
Здравствуйте, IT, Вы писали:
IT> Так себе, не самый лучший паттерн, от которого проблемы возникают сразу и по всему коду, а что он даёт ценного внятно не может объяснить ни один из его апологетов.
Согласен полностью и не могу не поделиться.
Имею вот щас на руках проект. Сервис обрабатывает разнообразные сообщения. DI доведен до абсурда. Ну т.е. вот буквально была поставлена цель — ни одного оператора new в коде. И казалось бы, оно имеет смысл — messaging же!
По принципу: обработчик резолвится через DI, получает в свой конструктор толпу объектов из DI, те, в свою очередь, тоже получают в свои конструкторы что-то из DI и т.д.
И что мы имеем? Несколько самых зубодробительных и в то же время самых критичных для юзера багов были связаны с ошибочным расшариванием непотокобезопасных объектов между обработчиками.
Тестами это дело, понятно, не детектируется никак. Ревью тоже бесполезен: попробуй-ка в уме сформируй этот развесистый граф объектов и пойми, что в нем не так. И выявляется только на продакшене, только под нагрузкой и только по абсолютно невразумительным ошибкам в логах.
И вот ты сидишь потом сутки, тупо глядя в лог и мозгуя, как же там могло образоваться именно такое вот исключение...
Здравствуйте, Dziman, Вы писали:
D>Я вот не могу понять это троллинг или что-то еще? Если 1 и 2 это константы то там DI делать нечего, но если эти значения приходят 'извне', то рано или поздно надо будет сделать getParam1 и getParam2. И там есть вероятность, что DI пригодится.
Может быть пригодится, а может быть скорее всего нет. Почему-то все понимают, что преждевременная оптимизация — это плохо, но решительно не понимают, что преждевременный дизайн — ещё хуже.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>Понятно. Разницы между библиотечной функцией общего назначения и логикой бизнес-приложения для тебя не существует.
Зависит от цели изучения кода и покрытия его логики тестами. Но то, что я не буду при каждом изучении кода смотреть что внутри каждого вызова — это факт. Сначала максимально локализовать проблему, а потом уже копаться.
IT>Опять начался детский сад. Судя по нашему предыдущему общению дальнейшая дискуссия с тобой начинает тепять всякий смысл. Пока.
Ну да, прошу не вешать ярлыки и смысл у тебя пропал сразу. Бывает
IT>Может быть пригодится, а может быть скорее всего нет. Почему-то все понимают, что преждевременная оптимизация — это плохо, но решительно не понимают, что преждевременный дизайн — ещё хуже.
преждевременный дизайн это плохо??
по всем исследованиям стоимость ошибки тем меньше, чем раньше она обнаружена, а раньше дизайна некуда,
разница между преждевременным дизайном и оптимизацией в том, что оптимизация это реально работающий (в продакшене) код, а дизайн это обычно писульки в визио,
задизайнить использование DI там где он не нужен это плохо не потому что дизайн преждевременный, а потому что такой дизайн — хренов
лично я предпочитаю без DI, но, на мой взгляд, архитектура с DI будет лучше чем архитектура созданная средним разработчиком без DI, но лучше чем хорошим разработчиком без DI
Здравствуйте, IT, Вы писали:
I>>Это больше на фобию похоже.
IT>Фобия — это боязнь, а бояться тут нечего. У меня стойкое отвращение. Фууу!
Ладно, годная отмазка. Вот другой пример
Есть задача — для кастомных модулей подменять функционал. Например у одного кастомера открытие документа это один воркфлоу, у другого — другой, у третьего — третий. Разница слишком большая что бы обкладывать ифами.
Есть некоторый АПИ, используемый внешними расширениями или скриптами, и есть АПИ внутренний, который наружу недоступен.
Вызов открытия документа снаружи достаточно простой — Application.Documents.Open(args);
Все что нужно сделать для другого кастомера — поменять логику открытия документа без необходимости городить конские иерархии наследования и тд.
Весь внутренний АПИ сделан примерно так. Есть N компонентов, похожих на команды или транзакции, интерфейс с вызывающей стороны примерно такой
Вот эта логика не меняется, её в принципе можно и генерить.
Скажем часть UI, это тулбары и меню, обновляется в зависимости от состояния приложения. Это всего лишь конфигурирование, при том в итоге вызывается чтото навроде barItem.StateFrom(cmd.Status) и конкретный итем будет исправно менять своё состояние без каких либо проблем.
Таких итемов примерно несколько сотен, может даже больше. Выписывать вьюмодельки совершенно неинтересно — вспотеешь учитывать все детали.
Фокус в том, что такие компоненты, как IOpenDocument, требуют целую кучу депенденсов, фактически, нужен весь АПИ приложения, и куча фунционала навроде зипа, скриптов и тд и тд и тд. Причем каждому нужно свое.
Внешний АПИ приложения не дает доступа ко всем сервисам, что очевидно. Внутренний сделан так, чт бы его можно было конфигурировать прозрачно для вызывающего кода
Решение получается такое
Все депенденсы при желании можно подложить свои собственные, отличные от дефолтных
Кроме того, каждый из компонентов может дергать и другие, такие же. Вызов по ряду причин, обычно делается не напрямую, т.к. для каждого компонента создается свой контекст и тд.
Вот так
var cmd = Resolve<ICommandYYY<TArgs>>();
cmd.Execute(args);
Очевидно, реализация ICommandYYY<TArgs> может варьироваться в зависимости от приложения. т.е. достаточно сконфигурировать.
На старте приложения DI подымает конфигурацию, а во время работы расставляет нужные депенденсы по требованию.
В итоге, со стороны кастомерского кода не надо возить с депенденсами. Со стороны внутреннего АПИ надо всего лишь объявить требуемые депенденсы. Унутре компонента все депенденсы уже будут в наличии.
Написание нового функционала сводится к таким вещам — объявить интерфейс, объявить депенденсы, написать внутреннюю логику. Вся инициализация и связывание перекладывается на DI.
БОлее того, на этот DI можно переложить контроль времени жизни некоторых объектов, можно сделать вложеные контексты и много чего другого.
Здравствуйте, evgeny.e, Вы писали:
EE>преждевременный дизайн это плохо??
Плохо. Всё преждевременное плохо. Послевременное тоже плохо. Хорошо только своевременное.
EE>по всем исследованиям стоимость ошибки тем меньше, чем раньше она обнаружена, а раньше дизайна некуда,
Ты говоришь про ошибочный дизайн, который чего-то не учитывает. Я говорю о дизайне, который учитыват всё подряд, но никому не нужное, т.е. представляет собой over design.
EE>разница между преждевременным дизайном и оптимизацией в том, что оптимизация это реально работающий (в продакшене) код, а дизайн это обычно писульки в визио,
Нет. Дизайн — это компоновка реально работающего. Есть алгоритмы и бизнес логика, есть их компоновка в классы, иерархии, компоненты, слои и т.п. Дизайн — это части и, самое глвное, связи между частями системы, код — это содержимое частей.
EE>задизайнить использование DI там где он не нужен это плохо не потому что дизайн преждевременный, а потому что такой дизайн — хренов
Хренов. Потому что препятствует отчуждению кода (части системы) от его контекста. Если статика прибивает гвоздями код к его контексту и не позволяет его в результате безболезненно отчуждать, то DI этот контекст наполняет и инициализирует неявно и непредсказуемо. Самый лучший код — это код, который при вызове получает весь необходимый контекст и внутри себя не пытается шаманить со статикой или DI. Такой код легко изолировать и перекомпоновывать под любой дизайн.
EE>лично я предпочитаю без DI, но, на мой взгляд, архитектура с DI будет лучше чем архитектура созданная средним разработчиком без DI, но лучше чем хорошим разработчиком без DI
Это как?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, evgeny.e, Вы писали:
EE>задизайнить использование DI там где он не нужен это плохо не потому что дизайн преждевременный, а потому что такой дизайн — хренов
плохой потому что плохой. Сильная идея. DI, там где он не нужен, плохой потому, что DI не нужен. Как-то так
Здравствуйте, IT, Вы писали:
IT>Самый лучший код — это код, который при вызове получает весь необходимый контекст и внутри себя не пытается шаманить со статикой или DI. Такой код легко изолировать и перекомпоновывать под любой дизайн.
Практически именно то, для чего и нужен DI — дать возможность компоненту при вызове получать весь необходимый контекст.
Вобщем, после таких слов для тебя самый удобный вариант это : "Заканчиваю троллить, иду работать"
Здравствуйте, Ikemefula, Вы писали:
I>>>Есть задача — для кастомных модулей подменять функционал. IT>>Ну подменяй. Что требуется от меня? I>Как аргумент в пользу DI годится или как ?
Надо смотреть. По крайней мере ты это используешь не для тестирования. Похоже, что у тебя нет другого выхода и ты вынужден использвать DI.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
IT>>Самый лучший код — это код, который при вызове получает весь необходимый контекст и внутри себя не пытается шаманить со статикой или DI. Такой код легко изолировать и перекомпоновывать под любой дизайн.
I>Практически именно то, для чего и нужен DI — дать возможность компоненту при вызове получать весь необходимый контекст.
Ты видимо прочитал лишь то, что хотел. Это бывает. Объясняю ещё раз. В случае DI объект получает не весь необходимый контекст, а вообще всё, что можно. При этом понять что именно объекту нужно, а что ему передали просто нереально. Поэтому при изучении кода, при его рефакторингах и модификациях, в случаях когда требуется отчуждение кода от системы, работа с таких кодом превращается в одну сплошную невыносимую головную боль.
I>Вобщем, после таких слов для тебя самый удобный вариант это : "Заканчиваю троллить, иду работать"
Вас очень сложно тролить. На любое моё "покажите код" у вас один ответ — "ты не понимаешь".
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
I>>>>Есть задача — для кастомных модулей подменять функционал. IT>>>Ну подменяй. Что требуется от меня? I>>Как аргумент в пользу DI годится или как ?
IT> Надо смотреть. По крайней мере ты это используешь не для тестирования. Похоже, что у тебя нет другого выхода и ты вынужден использвать DI.