MVVM Injection Dependency

Question

Я участвую в процессе обучения модели MVVM путем деления рисунка на его основные грани и изучения этих граней по одному.

Мой вопрос связан с инъекцией зависимости. Что это такое и почему/когда я должен его использовать? Я посмотрел отличный видеоролик MVVM Джейсона Долинджера, и я вижу, что он использует Unity. Это может быть странно спросить, но как я могу реализовать инъекцию зависимостей БЕЗ использования Unity? Я в основном хочу понять концепцию инъекции зависимостей и как ее использовать без необходимости реализации других фреймворков/инструментов (на данный момент).

Спасибо.

Answer 1

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

Предположим, вы хотите использовать какой-либо вид транспорта.

interface ITransportation 
{ 
    Transport(); 
} 

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

public void Move() 
{ 
    ITransportation car = new Car(); 
    car.Transport(); 
} 

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

public void Move(ITransportation tr) 
{ 
    tr.Transport(); 
} 

Как вы можете видеть, нам не нужно ничего знать о конкретном каркасе DI. Вы также можете ознакомиться с учебником ninject DI by hand.

Answer 2

Просто продлить @ ответ Энди

Dependency Injection является одной из форм Dependency Inversion Principle

, чтобы достичь развязки зависимостей (как правило, находится в многоуровневой архитектуре), DI обычно используется для конкретизации сценарии, такие как базовые новые() и шаблоны, подобные методу Factory. В дополнение к возможности каждый раз вводить новый экземпляр зависимостей (например, как на заводе), контейнеры также могут быть настроены для ввода именованных экземпляров, экземпляров singleton и т. Д. - например, контейнеры IoC обычно также берут на себя ответственность за управление жизненными циклами объектов также.

Один из возможных «сдвигов мышления» заключается в том, что зависимости теперь потенциально становятся общедоступными для конкретных классов, поскольку DI обычно вводит через конструкторы или публичные свойства Get/Set. Это может показаться странным, если вы привыкли использовать инкапсуляцию OO, где зависимости класса рассматриваются как реализация и должны быть скрыты от сигнатур метода «снаружи» i.e. class. Однако, реализуя разделение класса Interface/Concrete (как вы должны, не только для развязки, но и для тестирования/издевательства), методы инжекции конструкторов/свойств не будут находиться на интерфейсе, поэтому инкапсуляция снова будет на месте.

Re: «Выполнение DI вручную» без единства и т.д.

Что вам нужно будет сделать, это закодировать свой IoC контейнер, который затем отвечает за «построения» экземпляры классов - в течение каждого «build up», вы сканируете класс на зависимости (которые настроены в контейнере, например, по конфигурации, по атрибутам или просто по соглашению, например, все общедоступные настраиваемые свойства или любые параметры класса в конструкторе будут считаться быть зависимостями).Затем вы создадите (если необходимо) и введете этот экземпляр «зависимости» на объект (например, используя отражение). А затем рекурсивно, все зависимости этих зависимостей должны быть созданы и т. Д. Затем вам также потребуется обеспечить управление продолжительностью жизни для каждого из объектов, например. Синглтоны и т. Д.