Cel bloku aplikacji Unity w bibliotece Microsoft Enterprise?

Question

Czy ktoś może mi wyjaśnić, jaki jest cel bloku aplikacji Unity? Próbowałem przeglądać dokumentację, ale wszystko było bardzo abstrakcyjne.

Jakie są praktyczne zastosowania bloku Unity?

Answer 1

odwrócenie sterowania

Szybkie sumowania (dużo więcej czytania jest dostępny ten temat, a ja bardzo lektury więcej) ...

Zespół Microsoft Unity z zespołu Enterprise Patterns and Practices to projekt kontenera Inversion of Control lub skrót IoC. Podobnie jak Castle Windsor, StructureMap itp. Ten rodzaj rozwoju jest również określany w kategoriach Lame'a jako luźne łączenie twoich komponentów.

IoC zawiera wzorzec Dependency Injection twoich obiektów, w którym polegasz na komponencie zewnętrznym, aby połączyć zależności w obrębie twoich obiektów.

Na przykład, zamiast dostępu do statycznych menedżerów (które są prawie niemożliwe do testowania urządzenia), tworzy się obiekt, który opiera się na zależności zewnętrznej. Weźmy usługę Post, w której chcesz uzyskać dostęp do DB, aby uzyskać Post.

public class PostService : IPostService 
{ 
    private IPostRepository _postRepo; 

    public PostService(IPostRepository postRepo) 
    { 
    _postRepo = postRepo; 
    } 

    public IList<Post> GetPosts() 
    { 
    return _postRepo.GetAllPosts().ToList(); 
    } 
} 

Ten obiekt PostService ma teraz zewnętrzną zależność od IPostRepository. Zwróć uwagę, jak nie używa się betonów i klas statycznych menedżerów?Zamiast tego masz luźne sprzęgnięcie z z prostego interfejsu - co daje ci możliwość okablowania wszystkich rodzajów klas konkretnych, które implementują IPostRepository.

Celem Microsoft Unity jest automatyczne podłączenie do tego IPostRepository. Więc nie musisz się martwić o zrobieniu:

// you never have to do this with Unity 
IPostRepository repo = new PostRepository(); 
IPostService service = new PostService(repo); // dependency injection 
IList<Post> posts = service.GetPosts(); 

Powyższe pokazuje, gdzie trzeba realizować dwa konkretne zajęcia, PostRepository() i Postservice(). To ściśle wiąże twoją aplikację z żądaniem/wymaga tych dokładnych przypadków i bardzo utrudnia test jednostkowy.

Zamiast tego należy użyć jedność w swoim punkcie końcowym (kontrolera w MVC lub kod tyłu na stronach ASPX):

IUnityContainer ioc = new UnityContainer(); 
IPostService postService = ioc.Resolve<IPostService>(); 
IList<Post> posts = postService.GetPosts(); 

Zauważ, że nie istnieją żadne użyte w tym przykładzie (z wyjątkiem UnityContainer i Poczty betony , oczywiście)! Brak konkretnych usług i nie ma repozytorium. To luźno sprzęga się w najlepszym wydaniu.

Oto prawdziwy kicker ...

Jedności (lub jakimkolwiek pojemniku ramy IoC tam!) Poddadzą IPostService żadnych zależności. Zobaczy, że chce (zależy) od instancji IPostRepository. Tak więc, Unity przejdzie do jego mapy obiektów i poszukać pierwszego obiektu, który implementuje IPostRepository, który został zarejestrowany w kontenerze, i zwróci go (to jest instancja SqlPostRepository). To jest prawdziwa siła stojąca za strukturami IoC - możliwość kontrolowania usług i automatycznego łączenia dowolnych zależności.

Muszę dokończyć mój post na blogu o porównaniach UNITY vs Castle vs StructureMap. Właściwie wolę Castle Windsor ze względu na opcje pliku konfiguracyjnego i punkty rozszerzalności osobiście.

Answer 2

Blok aplikacji Unity jest używany do dependency injection. Myślę, że najlepszym prosta definicja DI wynosi od this question

Kiedy idziesz i dostać rzeczy z lodówki dla siebie, można spowodować problemy. Możesz zostawić drzwi otwarte, możesz dostać coś, czego mama lub tatuś nie chcą mieć. Możesz nawet szukać czegoś, czego nawet nie posiadamy lub które wygasło.

To, co powinieneś robić, to stwierdzenie, że "potrzebuję czegoś do picia z obiadem", a wtedy upewnimy się, że masz coś, gdy siadasz do jedzenia.

Tak dla przykładu,

IUnityContainer container = new UnityContainer(); 
ILunch lunch = container.Resolve<ILunch>(); 
Console.WriteLine(lunch.Drink); 

Ten Wyjścia "Lemonade", ponieważ zdefiniowane Drink jako zależność.

public class ILunch { 
    [Dependency] 
    public IDrink Drink { get; set; } 
} 

Jeśli chodzi o praktyczność idzie, Dependency Injection jest naprawdę świetne, gdy masz współzależności z innymi przedmiotami i nie chcesz, deweloper musiał ręcznie ustawić je. To takie proste. Świetnie nadaje się również do kpiny. Najczęściej używanym przykładem, jaki mogę sobie wyobrazić, jest kpiny z warstwy danych. Czasami baza danych nie jest gotowa, więc zamiast zatrzymywać rozwój, mam fałszywą warstwę, która zwraca fałszywe dane. Obiekt danych jest dostępny przez DI i może być skonfigurowany do zwracania obiektów, które uzyskują dostęp do fałszywej warstwy lub rzeczywistej warstwy. W tym przykładzie prawie używam kontenera DI jako konfigurowalnej klasy fabrycznej. Więcej informacji na temat Unity MSDN ma kilka świetnych zasobów http://msdn.microsoft.com/en-us/library/cc468366.aspx.

Inne dobre DI szkieletowe obejmują Spring.NET i Ninject