Shocker.ProЯ исхожу из посыла Симана, на котором он категорически настаивает: Resolve используется один раз, все остальные зависимости подгружаются уже автоматически через DI. Иначе ломается вся схема DI, и, если вызывать Resolve на более глубоких слоях, паттерн начинает превращаться в Service Locator, который Симан считает антипаттерном.

Что подсказывает ваш опыт? Нужно ли этому правилу следовать неукоснительно? Или без фанатизма: применять Resolve глубже, если таким образом упрощается структура кода.

я полностью согласен с этим утверждением. надо категорически избегать использовать Service Locator. вариантов масса. можно передавать фабрики. в самом крайнем случае можно резолвить сам контейнер, но обычно мне удавалось обойтись без него.

могут быть моменты, где без Service Locator тяжело обойтись. это часть кода, который уже написан кем-то другим без внедрения зависимостей. в той части, если что-то дописывать, передавать какие-нибудь классы, придётся дёргать SL. в штатной ситуации SL не нужен.


Shocker.ProЧасто класс создается с конкретными параметрами, передаваемыми через конструктор, после чего класс готов к употреблению. Причем параметры заранее неизвестны (парамеры рантайма). То есть два пути получается:

2а) отказываться от инициализации класса в конструкторе и вводить понятие "неинициализированного класса" и контроль за тем, чтобы неинициализированный класс не мог использоваться, специальный метод инициализации.

2б) делать абстрактную фабрику под каждый конкретный класс и внедрять ее как зависимость

В общем, дополнительный гемор или как?

классы, которые требуют внедрения зависимостей не надо создавать вручную. дополнительные параметры в таком случае передаются:

а) либо через публичные свойства
б) либо через инициализатор

ещё вариант, внедрять фабрику, которая может инстанцировать класс с набором конкретных параметров.


Shocker.ProЭто как вариант второго пункта, то есть отказываться от перегруженных конструкторов в принципе и идти по принципу отдельной инициализации класса или персональной фабрики?

Тут я приведу конкретный пример, возможно я не прав с архитектурой. Я упрощаю, надо иметь ввиду, что реальный класс несколько сложней. Пример в контексте ASP.NET MVC: есть некая модель бизнес-уровня - к примеру "карточка клиента", содержащая некоторое количество полей (необязательно элементарных). Модель инкапсулирует некоторые проверки, взаимодействие с репозиторием и некоторые другие функции). Модель может быть создана тремя путями: а) создание нового клиента (при этом в конструкторе может быть несколько предустановок, например "родительский клиент") б) загрузка из базы (в конструкторе передается id) в) создание на основе введенных пользователем данных (в конструктор передается пул введенных значений).

Все это удобно реализуется тремя перегрузками конструктора. Как изменить подход, чтоб внедрить DI?

однозначно все 3 способа плохи для конструкторов. этим должна озаботиться фабрика, или на крайний случай фабричный метод.

Shocker.ProОпять же пример из жизни MVC: классу контроллера может потребоваться зависимость от нескольких моделей, но реально будет использоваться одна-две, в зависимости как от вызванного метода (Action), так и, например, от результатов валидации. Внедрять зависимости от всех моделей? зачем ему этот ворох? Бить контроллер на множество мелких контроллеров? Тоже не очень удобный вариант: зачем мы тогда вообще объединяем несколько методов в контроллер.

один из вариантов, это использовать ленивую инициализацию Lazy<T>. можно использовать в параметрах конструктора или в публичных свойствах. бить контроллер не надо. можно аггрегировать наборы в специальные классы. или опять же фабрики. но Lazy<T> самый простой вариант.

gandjustasАбстрактная фабрика не нужна, конейнер и есть такая фабрика.

Перестань вводить людей в заблуждение. Контейнер не есть фабрика, хотя может выполнять её функции.

Shocker.Proто есть под каждый класс сущности делать персональную фабрику, предназначенную именно для этого класса? (универсальная типобезопасная фабрика не получится из-за того, что у классов есть специфические параметры создания)

Без конкретной задачи, трудно сказать что будет лучше. Но в целом да, или фабричный метод (который может нести на борту сам класс, можно получать его через функтор).

Если на момент создания ты знаешь какой конструктор надо использовать (в твоём варианте), значит ты также будешь знать какую фабрику использовать. Только во втором случае фабрика будет получена через DI, и получит все требуемые зависимости.

Ещё вариант, в случае Autofac, можно определить сложный процесс инстанцирования класса с выбором нужного контруктора, но это плохо сопровождается, хотя и меньше кода.

Shocker.Proимеется ввиду System.Lazy<T>? Ок, прикину этот способ на свои задачи.

Ага. По мне, так очень удобно.

gandjustasЕсли надо руками создавать фабрики, то выбрасывай контейнер, он бесполезен.

Чумовой бред.

Shocker.ProНу, собственно, я и пытаюсь найти ту границу разумного использования DI. Мне как раз неясно, как быть, если класс, создаваемый через new хочет зависимость, которая в других случаях настраивается через контейнер? Вручную транслировать все (или сам контейнер) через конструктор?

Зависимости надо снижать. Например DTO классы не должны быть зависимыми. Если есть зависимость и архитектура строится на DI, то надо использовать DI. Тут тяжело сказать, где граница применения DI, её итак видно неплохо. Там где можно избежать использовать DI, над избегать. Тут уже придёт с опытом, теоретически это плохо формализуется.

Shocker.Proиспользую Autofac.
То есть, фактически, это создание нового графа? То есть точка резолва корня этого графа перемещается вглубь вызовов классов?

Да. Но таких моментов должно быть по-меньше. На границе сервисов с разным способом управления времени жизни.

Shocker.ProМеня, может быть смутило то, что в этой главе Симан очень фанатично использует DI, вплоть до того, что развязывает модель с репозиторием за счет дополнительной абстрации в виде промежуточного сервиса, заточенного практически персонально под модель.

Когда тебе надо будет покрыть код тестами приблизительно на 100%, ты поймёшь Симана

ViPRosзначит главно что бы прога хорошо тестировалась?
ребятя вы потиноьку съезжаете с ума

человек совершает ошибки. всегда. даже если это Бог Программирования. тем более при методологии CI, это практически обязательное требование. или по-вашему после каждой небольшой правки в коде необходимо загонять толпу QA и проверять абсолютно всё заново? ну-ну. удачи вам. как только сделаете ЗП каждому тестеру по $10k, я сам лично буду готов работать таким авто-тестером.

Konst_Oneну так для этого и было придумано, unit test-ы всякие и тп.
безусловно, нечего IoC/DI огород городить для обычных приложений

именно. все истерические вопли по поводу IoC/DI связаны с полным отсутствием какого-либо опыта.

ЕвгенийВМожет то может быт и может. Только часто это превращается 100500 интерфейсов, от которых унаследовано всего по одному классу и полную путаницу, что и от чего зависит и откуда берется. Или там разделение ответственности доводят до полного бреда....

Не надо путать божий дар с яичницей! Даже с плохим ножом профессиональный повар приготовит шедевр, а с профессиональным ножом профан нарежет овощей вперемешку со своими пальцами.

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