Co to jest Castle Windsor i dlaczego powinienem się tym przejmować?

Jestem wieloletnim programistą Windows, który obciął mnie zębami w systemie Windows 32 i wczesnym COM. Pracuję z .NET od 2001 roku, więc jestem dość biegły w C # i CLR. Nigdy nie słyszałem o Castle Windsor, dopóki nie zacząłem brać udziału w Stack Overflow. Przeczytałem przewodnik „Pierwsze kroki” w Castle Windsor, ale nie można go kliknąć.

Naucz tego starego psa nowych sztuczek i powiedz mi, dlaczego powinienem integrować Castle Windsor z aplikacjami dla przedsiębiorstw.

Castle Windsor to narzędzie do odwracania kontroli. Są tacy inni.

Może dać ci obiekty ze wstępnie zbudowanymi i okablowanymi zależnościami. Cały wykres obiektu utworzony za pomocą odbicia i konfiguracji zamiast „nowego” operatora.

Zacznij tutaj: http://tech.groups.yahoo.com/group/altdotnet/message/10434

Wyobraź sobie, że masz zajęcia wysyłania wiadomości e-mail. EmailSender. Wyobraź sobie, że masz inną klasę WorkflowStepper. Wewnątrz WorkflowStepper musisz użyć EmailSender.

Zawsze możesz powiedzieć new EmailSender().Send(emailMessage);

ale to - użycie new- tworzy ciasne SPRZĘGŁO, które trudno zmienić. (w końcu to mały wymyślony przykład)

Co więc, jeśli zamiast nowego tego złego chłopca w WorkflowStepper, właśnie przekazałeś go konstruktorowi?

Zatem ktokolwiek to nazwał, musiał założyć EmailSender.

new WorkflowStepper(emailSender).Step()

Wyobraź sobie, że masz setki tych małych klas, które mają tylko jedną odpowiedzialność (google SRP) .. i używasz kilku z nich w WorkflowStepper:

new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()

Wyobraź sobie, że nie martwisz się szczegółami, EmailSenderkiedy piszesz WorkflowStepperlubAlertRegistry

Martwisz się o problem, z którym pracujesz.

Wyobraź sobie, że cały wykres (drzewo) obiektów i zależności jest łączony w czasie RUN TIME, więc kiedy to zrobisz:

WorkflowStepper stepper = Container.Get<WorkflowStepper>();

dostajesz prawdziwą ofertę na WorkflowStepperwszystkie zależności automatycznie wypełniane tam, gdzie ich potrzebujesz.

Nie ma new

Tak się po prostu dzieje - bo wie, czego potrzebuje.

I możesz pisać mniej defektów dzięki lepiej zaprojektowanemu, DRY kodowi w testowalny i powtarzalny sposób.

Mark Seemann napisał doskonałą książkę o DI (Dependency Injection), która jest podzbiorem MKOl. Porównuje także wiele pojemników. Nie mogę wystarczająco polecić tej książki. Książka nazywa się: „Dependency Injection in .Net” https://www.manning.com/books/dependency-injection-in-dot-net

Myślę, że IoC jest krokiem we właściwym kierunku na drodze do większej wydajności i radości zespołu programistów (w tym PM, BA i BO). Pomaga ustalić rozdzielenie problemów między programistami a testowaniem. Daje to spokój podczas projektowania, co pozwala na elastyczność, ponieważ ramy mogą wchodzić i wychodzić.

Najlepszym sposobem na osiągnięcie celu, który stawia sobie za cel IoC (CW lub Ninject itp.), Jest wyeliminowanie polityki nr 1 i nr 2, które eliminują potrzebę tworzenia przez deweloperów fałszywego zrozumienia podczas tworzenia. Czy te dwa rozwiązania nie wydają się powiązane z IoC? Oni są :)

Castle Windsor jest Dependency Injection container.Dzięki temu możesz wprowadzić swoje zależności i używać ich bez tworzenia ich za pomocą nowego słowa kluczowego. np. zastanów się, że napisałeś repozytorium lub usługę i chcesz z niego korzystać w wielu miejscach, musisz najpierw zarejestrować swoją usługę / repozytorium i możesz zacząć z niego korzystać po wstrzyknięciu go w wymagane miejsce. Możesz rzucić okiem na poniższy samouczek, który śledziłem, aby nauczyć się zamku windsor.

link .

Mam nadzieję, że ci to pomoże.

Mówiąc prościej. Wyobraź sobie, że masz w swojej klasie zakopaną klasę, która potrzebuje kilku prostych wartości konfiguracyjnych do wykonania swojej pracy. Oznacza to, że wszystko, co tworzy instancję tej klasy, musi uzyskać te zależności, dlatego zwykle po drodze trzeba przefakturować mnóstwo klas, aby przekazać konfigurację do miejsca, w którym instancja zostanie utworzona.

Tak więc albo wiele klas jest niepotrzebnie zmienianych, grupujesz wartości konfiguracji w jedną dużą klasę konfiguracji, która jest również zła ... lub, co najgorsze, nadal lokalizujesz Service Locator!

IoC pozwala twojej klasie uzyskać wszystkie swoje zależności bez tego kłopotu, i bardziej precyzyjnie zarządza czasem życia instancji.