Паттерны внедрения зависимостей. Часть 1

[tarakanoff]

Что может быть обязательной зависимостью и необязательной, примеры? Можно несколько примеров, если не сложно.

[pankraty]

Например, для PersonService обязательно зависимостью может быть IPersonRepository, а для PersonRepository — IDbContext.

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

[SomeOneThere]

Сериализатор по умолчанию?

[marshinov]

«Необязательные зависимости» довольно часто свидетельствуют о нарушении SRP и приводят к NRE. Так что лучше без них.

[tmteam]

Почему? Приведите пример.

[marshinov]

Как гарантировать, что вызов DoSomething из вашего примера произойдет после того как Dependency будет установлен?

[tmteam]

Зачем я должен это гарантировать? Если я пробрасываю зависимость через свойство, то я тем самым говорю «Есть поведение и вы можете менять его в любой момент». Яркий пример — зазоры для тестирования. Вы же не хотите передавать все параметры включая NowTimeLocator, ThreadSleeper, итд каждый раз.

[atepeq]

Можно было бы дать ссылки на посты Сергея Теплякова, откуда текст перекочевал целыми абзацами:
sergeyteplyakov.blogspot.com/2013/01/di-property-injection.html
sergeyteplyakov.blogspot.com/2012/12/di-constructor-injection.html

[Sinatr]

В property injection:

Трудность возникает, если клиентам будет позволено менять значение зависимости в течение жизненного цикла класса.

Вы запретили клиентам вызывать сеттер более одного раза, но между вызовом конструктора и вызовом сеттера есть промежуток времени, в течении которого значения будет «изменено» со значения по умолчанию на новое. Особенно мне не нравится установка дефолтового значения в геттере. Почему яно не использовать Lazy?

Property-injection используется для необязательной зависимости и в зависимости от того, что делает дефолтовая реализация, может даже имеет смысл делать null-проверки в коде локально, каждый раз при обращении к экземпляру. Всегда имплементировать реализацию, которая «ничего не делает» — как-то накладно.

По-моему лучше необязательную injection делать через оверлоад конструктора, для property-injection требуется, чтобы зависимость обладала «некими» специфическими свойствами, к примеру, чтобы уже существовала дефолтовая имплементация, которая позволит избежать спагетти-кода из-за null-проверок.

придется либо делать свойство только для записи (set-only property), что противоречит общепринятым принципам проектирования на платформе .NET

Каким таким «общепринятым» принципам? Есть guidelines, где написано "X DO NOT provide set-only properties"

[JosefDzeranov]

Зачем тогда придумали методы?