Это более техническое описание фона, надеюсь, вы по-прежнему найдете его полезным.
Обычно это контейнер DI (внедрение зависимостей).
Дан следующий класс:
public class Sample
{
Service a;
public Sample()
{
a = new Service();
}
}
Проблема в том, что он инициализирует свою собственную версию Service
, что делает его очень трудным для адаптации к изменениям кода (т. Е. Если вы хотите заменить Service
на что-то другое). Также это затрудняет тестирование.
Чтобы решить эту проблему, на самом деле не создавайте его самостоятельно, а получите его извне:
public class Sample
{
Service a;
public Sample(Service aService)
{
a = aService;
}
}
Теперь вы забрали создание из класса, вы можете просто поместить его туда снаружи, что повышает тестируемость и ремонтопригодность. Однако у вас все еще есть зависимость от класса Service
. Вы на самом деле не заинтересованы в этом конкретном классе, но в поведении, которое он предлагает - поэтому вы делаете из него интерфейс.
public class Sample
{
IService a;
public Sample(IService aService)
{
a = aService;
}
}
Теперь вы можете заменить услугу на что угодно. Например, у вас есть класс, получающий данные с сервера с помощью службы. Теперь вы хотите протестировать только парсинг данных, а не сервис извлечения данных - просто создайте класс, реализующий интерфейс, обслуживающий статические данные, - готово!
Теперь в игру вступает Unity. На данный момент вы должны разрешить зависимости самостоятельно. Единство делает просто - оно берет все классы, которые имеют зависимости, и разрешает их - так что вы можете просто вызвать (псевдокод, я не знаю единство):
UnityContainer uc = new UnityContainer();
var a = uc.GetService<IService>();
И это дает вам готовый к использованию класс.
Чего мы достигли этим?
- код более удобен в обслуживании, поскольку вы не полагаетесь на определенные типы
- код более тестируемый
- приложение легко расширяется
В заключение: это помогает быстрее создавать лучшие приложения.