Кто-то может объяснить Microsoft Unity?
Я знаю его старый вопрос, но с точки зрения перечисления невоспроизводимых файлов я думал, что добавлю еще один, в котором также перечислены невоспроизводимые папки:
Вы можете использовать операцию git clean с -n (сухой пробег ), чтобы показать вам, какие файлы он будет удалять (включая файлы .gitignore):
git clean -xdn
. Это имеет преимущество при отображении всех файлов и всех папок, которые не отслеживаются , Параметры:
-
x- Показывает все необработанные файлы (в том числе игнорируются git и другими, например, вывод сборки и т. Д.) -
d- показывать неподписанные каталоги -
n- и самое главное! - dryrun, т. е. фактически ничего не удалять, просто используйте чистый механизм для отображения результатов.
4 ответа
Единицей является просто МОК "контейнер". Google StructureMap и испытывает его вместо этого. Немного легче к grok, я думаю, когда материал МОК в новинку для Вас.
В основном, если Вы понимаете МОК тогда, Вы понимаете, что то, что Вы делаете, инвертирует управление для того, когда объект создается.
Без МОК:
public class MyClass
{
IMyService _myService;
public MyClass()
{
_myService = new SomeConcreteService();
}
}
С контейнером МОК:
public class MyClass
{
IMyService _myService;
public MyClass(IMyService myService)
{
_myService = myService;
}
}
Без МОК, Ваш класс, который полагается на IMyService, имеет к новому конкретную версию сервиса использовать. И это плохо по ряду причин (Вы связали свой класс с определенной конкретной версией IMyService, Вы не можете модульный тест это легко, Вы не можете изменить его легко, и т.д.)
С контейнером МОК, Вы "настраиваете" контейнер для разрешения тех зависимостей для Вас. Таким образом с основанной на конструкторе инжекционной схемой, Вы просто передаете интерфейс зависимости IMyService в конструктора. При создании MyClass с контейнером контейнер разрешит зависимость IMyService для Вас.
Используя StructureMap, настраивая контейнер похож на это:
StructureMapConfiguration.ForRequestedType<MyClass>().TheDefaultIsConcreteType<MyClass>();
StructureMapConfiguration.ForRequestedType<IMyService>().TheDefaultIsConcreteType<SomeConcreteService>();
Поэтому тому, что Вы сделали, говорят контейнер, "Когда кто-то запрашивает IMyService, дайте им копию SomeConcreteService". И Вы также определили, что, когда кто-то просит MyClass, они получают конкретный MyClass.
Это - весь, контейнер МОК действительно делает. Они могут сделать больше, но это - тяга его - они разрешают зависимости для Вас, таким образом, Вы не имеете к (и Вы не должны использовать "новое" ключевое слово всюду по своему коду).
Заключительный шаг: при создании MyClass Вы сделали бы это:
var myClass = ObjectFactory.GetInstance<MyClass>();
Hope, которая помогает. Не стесняйтесь посылать мне по электронной почте.
Единицей является МОК. Точка МОК должна абстрагировать проводное соединение зависимостей между типами за пределами самих типов. Это имеет несколько преимуществ. В первую очередь, это сделано централизованно, что означает, что Вы не должны изменять много кода, когда зависимости изменяются (который может иметь место для модульных тестов).
, Кроме того, если проводное соединение сделано с помощью данных конфигурации вместо кода, можно на самом деле повторно соединить зависимости проводом после развертывания и таким образом изменить поведение приложения, не изменяя код.
Единица является библиотекой как многие другие, которая позволяет Вам получать экземпляр требуемого типа, не имея необходимость создавать ее самим. Так данный.
public interface ICalculator
{
void Add(int a, int b);
}
public class Calculator : ICalculator
{
public void Add(int a, int b)
{
return a + b;
}
}
Вы пользовались бы библиотекой как Единица для регистрации Калькулятора, который будет возвращен, когда тип, ICalculator требуют иначе МОК (Инверсия Управления) (этот пример является теоретическим, не технически корректным).
IoCLlibrary.Register<ICalculator>.Return<Calculator>();
Поэтому теперь, когда Вы хотите экземпляр ICalculator Вы просто...
Calculator calc = IoCLibrary.Resolve<ICalculator>();
библиотеки IoC могут обычно настраиваться, чтобы или содержать одиночный элемент или создать новый экземпляр каждый раз, когда Вы разрешаете тип.
Теперь скажем, у Вас есть класс, который полагается на ICalculator для присутствования, Вы могли иметь..
public class BankingSystem
{
public BankingSystem(ICalculator calc)
{
_calc = calc;
}
private ICalculator _calc;
}
И можно установить библиотеку для введения объекта в конструктора, когда она создается.
Так DI или Внедрение зависимости означает вводить любой объект, которого другой мог бы потребовать.
I just watched the 30 minute Unity Dependency Injection IoC Screencast by David Hayden and felt that was a good explaination with examples. Here is a snippet from the show notes:
The screencast shows several common usages of the Unity IoC, such as:
- Creating Types Not In Container
- Registering and Resolving TypeMappings
- Registering and Resolving Named TypeMappings
- Singletons, LifetimeManagers, and the ContainerControlledLifetimeManager
- Registering Existing Instances
- Injecting Dependencies into Existing Instances
- Populating the UnityContainer via App.config / Web.config
- Specifying Dependencies via Injection API as opposed to Dependency Attributes
- Using Nested ( Parent-Child ) Containers