То, что вы видите, на самом деле является анти-паттерном Service Locator . Пример кода напрямую ссылается на контейнер, вызывая его метод Resolve ().
В 99% случаев вам никогда не следует ссылаться на ваш контейнер в вашем коде - должна быть только одна ссылка на контейнер в приложении на самом высоком уровне вашего кода. (последние 1% случаев почти исключительно связаны с тем, что используемая вами среда не позволяет внедрять зависимости)
В этой единственной ссылке на ваш контейнер вы обновляете объекты по мере необходимости со всеми их зависимостями, введенными в допустимом состоянии. Все ваши объекты получают свои зависимости в виде параметров (чаще всего передаются в конструктор).
Есть много постов в блоге (вот два, которые я нашел с некоторым быстрым поиском в Google: Не ссылаться на Контейнер IoC и Сервисный локатор - это антишаблон вокруг объяснения различных причины плохого ServiceLocator.
Вы нашли один пример с вашим вопросом о том, каким должен быть loggerType, при использовании надлежащего IoC ваше приложение не должно заботиться - подход Service Locator обычно означает, что ваше приложение снова начинает осознавать детали своих зависимостей, что противоречит весь смысл использования IoC и внедрения зависимостей в первую очередь.
Для дальнейшего чтения по IoC я бы предложил просмотреть посты в блоге Джереми Миллера, создателя StructureMap . Не принимайте это, как я сказал, используйте StructureMap вместо Unity, но, поскольку он написал контейнер с нуля, большая часть того, что он говорит по этому вопросу, хорошо продумана, и он хороший писатель.