Сообщение Re[6]: О пользе Dependency Injection от 15.01.2021 15:10
Изменено 18.01.2021 14:34 IT
Re[6]: О пользе Dependency Injection
Здравствуйте, petroa, Вы писали:
P>Это ведь вроде, так или иначе, придётся делать самому. Можно делегировать ioc-контейнеру. Интересно ваше мнение.
Дело не в конфигурации. Обрати внимание, нелюбители DI фреймворков сетуют прежде всего на то, что с таким кодом сложно разбираться. Это действительно так. Это сложно понять, если ты написал пару проектов исключительно как писатель и не занимался их поддержкой продолжительное время. А ещё лучше это прочувствовать на чужом коде. Вот представь, у тебя есть простейший код:
Код кидает исключение. Твоя задача — найти причину. Если код без DI фрейворков, то эта задача из разряда примитивных. Shift-F12 в студии (R#?) покажет тебе абсолютно все вызовы конструктора и далее по цепочке можно раскрутить всё даже без необходимости запускать этот код. Если же используется DI фреймворк, то для того, чтобы понять что происходит необходимо запускать как минимум отладчик. При этом возникает несколько проблем.
— этот код может находится в трудно доступном месте и для его выполнения потребуется создание определённого сценария, подготовки окружения и набора данных.
— проблема может возникать только в определённом окружении недоступном для отладки, а при создании искуственных условий проблема не воспроизводится.
При наихудшем сценарии проблему всё равно придётся решать путём анализа кода, но в случае с DI фреймворком это на порядок сложнее.
И здесь я опять вынужден повторить свой вопрос. Какую проблему решают DI фреймворки, которая по своей значимости способна перевесить вносимые в проект неудобства?
P>Это ведь вроде, так или иначе, придётся делать самому. Можно делегировать ioc-контейнеру. Интересно ваше мнение.
Дело не в конфигурации. Обрати внимание, нелюбители DI фреймворков сетуют прежде всего на то, что с таким кодом сложно разбираться. Это действительно так. Это сложно понять, если ты написал пару проектов исключительно как писатель и не занимался их поддержкой продолжительное время. А ещё лучше это прочувствовать на чужом коде. Вот представь, у тебя есть простейший код:
class Foo
{
public Foo(Bar b)
{
if (b == null)
throw ...
}
}Код кидает исключение. Твоя задача — найти причину. Если код без DI фрейворков, то эта задача из разряда примитивных. Shift-F12 в студии (R#?) покажет тебе абсолютно все вызовы конструктора и далее по цепочке можно раскрутить всё даже без необходимости запускать этот код. Если же используется DI фреймворк, то для того, чтобы понять что происходит необходимо запускать как минимум отладчик. При этом возникает несколько проблем.
— этот код может находится в трудно доступном месте и для его выполнения потребуется создание определённого сценария, подготовки окружения и набора данных.
— проблема может возникать только в определённом окружении недоступном для отладки, а при создании искуственных условий проблема не воспроизводится.
При наихудшем сценарии проблему всё равно придётся решать путём анализа кода, но в случае с DI фреймворком это на порядок сложнее.
И здесь я опять вынужден повторить свой вопрос. Какую проблему решают DI фреймворки, которая по своей значимости способна перевесить вносимые в проект неудобства?
Re[6]: О пользе Dependency Injection
Здравствуйте, petroa, Вы писали:
P>Это ведь вроде, так или иначе, придётся делать самому. Можно делегировать ioc-контейнеру. Интересно ваше мнение.
Дело не в конфигурации. Обрати внимание, нелюбители DI фреймворков сетуют прежде всего на то, что с таким кодом сложно разбираться. Это действительно так. Это сложно понять, если ты написал пару проектов исключительно как писатель и не занимался их поддержкой продолжительное время. А ещё лучше это прочувствовать на чужом коде. Вот представь, у тебя есть простейший код:
Код кидает исключение. Твоя задача — найти причину. Если код без DI фрейворков, то эта задача из разряда примитивных. Shift-F12 в студии (R#?) покажет тебе абсолютно все вызовы конструктора и далее по цепочке можно раскрутить всё даже без необходимости запускать этот код. Если же используется DI фреймворк, то для того, чтобы понять что происходит необходимо запускать как минимум отладчик. При этом возникает несколько проблем.
— этот код может находится в трудно доступном месте и для его выполнения потребуется создание определённого сценария, подготовки окружения и набора данных.
— проблема может возникать только в определённом окружении недоступном для отладки, а при создании искуственных условий проблема не воспроизводится.
При наихудшем сценарии проблему всё равно придётся решать путём анализа кода, но в случае с DI фреймворком это на порядок сложнее.
И здесь я опять вынужден повторить свой вопрос. Какую проблему решают DI фреймворки, которая по своей значимости способна перевесить вносимые в проект неудобства?
P>Это ведь вроде, так или иначе, придётся делать самому. Можно делегировать ioc-контейнеру. Интересно ваше мнение.
Дело не в конфигурации. Обрати внимание, нелюбители DI фреймворков сетуют прежде всего на то, что с таким кодом сложно разбираться. Это действительно так. Это сложно понять, если ты написал пару проектов исключительно как писатель и не занимался их поддержкой продолжительное время. А ещё лучше это прочувствовать на чужом коде. Вот представь, у тебя есть простейший код:
class Foo
{
public Foo(Bar b)
{
if (!b.IsValid)
throw ...
}
}Код кидает исключение. Твоя задача — найти причину. Если код без DI фрейворков, то эта задача из разряда примитивных. Shift-F12 в студии (R#?) покажет тебе абсолютно все вызовы конструктора и далее по цепочке можно раскрутить всё даже без необходимости запускать этот код. Если же используется DI фреймворк, то для того, чтобы понять что происходит необходимо запускать как минимум отладчик. При этом возникает несколько проблем.
— этот код может находится в трудно доступном месте и для его выполнения потребуется создание определённого сценария, подготовки окружения и набора данных.
— проблема может возникать только в определённом окружении недоступном для отладки, а при создании искуственных условий проблема не воспроизводится.
При наихудшем сценарии проблему всё равно придётся решать путём анализа кода, но в случае с DI фреймворком это на порядок сложнее.
И здесь я опять вынужден повторить свой вопрос. Какую проблему решают DI фреймворки, которая по своей значимости способна перевесить вносимые в проект неудобства?