Facebook - konwersja
Czytaj fragment
Pobierz fragment

Wstrzykiwanie zależności - ebook

Data wydania:
1 stycznia 2020
Format ebooka:
EPUB
Format EPUB
czytaj
na czytniku
czytaj
na tablecie
czytaj
na smartfonie
Jeden z najpopularniejszych formatów e-booków na świecie. Niezwykle wygodny i przyjazny czytelnikom - w przeciwieństwie do formatu PDF umożliwia skalowanie czcionki, dzięki czemu możliwe jest dopasowanie jej wielkości do kroju i rozmiarów ekranu. Więcej informacji znajdziesz w dziale Pomoc.
Multiformat
E-booki w Virtualo.pl dostępne są w opcji multiformatu. Oznacza to, że po dokonaniu zakupu, e-book pojawi się na Twoim koncie we wszystkich formatach dostępnych aktualnie dla danego tytułu. Informacja o dostępności poszczególnych formatów znajduje się na karcie produktu.
, MOBI
Format MOBI
czytaj
na czytniku
czytaj
na tablecie
czytaj
na smartfonie
Jeden z najczęściej wybieranych formatów wśród czytelników e-booków. Możesz go odczytać na czytniku Kindle oraz na smartfonach i tabletach po zainstalowaniu specjalnej aplikacji. Więcej informacji znajdziesz w dziale Pomoc.
Multiformat
E-booki w Virtualo.pl dostępne są w opcji multiformatu. Oznacza to, że po dokonaniu zakupu, e-book pojawi się na Twoim koncie we wszystkich formatach dostępnych aktualnie dla danego tytułu. Informacja o dostępności poszczególnych formatów znajduje się na karcie produktu.
(2w1)
Multiformat
E-booki sprzedawane w księgarni Virtualo.pl dostępne są w opcji multiformatu - kupujesz treść, nie format. Po dodaniu e-booka do koszyka i dokonaniu płatności, e-book pojawi się na Twoim koncie w Mojej Bibliotece we wszystkich formatach dostępnych aktualnie dla danego tytułu. Informacja o dostępności poszczególnych formatów znajduje się na karcie produktu przy okładce. Uwaga: audiobooki nie są objęte opcją multiformatu.
czytaj
na tablecie
Aby odczytywać e-booki na swoim tablecie musisz zainstalować specjalną aplikację. W zależności od formatu e-booka oraz systemu operacyjnego, który jest zainstalowany na Twoim urządzeniu może to być np. Bluefire dla EPUBa lub aplikacja Kindle dla formatu MOBI.
Informacje na temat zabezpieczenia e-booka znajdziesz na karcie produktu w "Szczegółach na temat e-booka". Więcej informacji znajdziesz w dziale Pomoc.
czytaj
na czytniku
Czytanie na e-czytniku z ekranem e-ink jest bardzo wygodne i nie męczy wzroku. Pliki przystosowane do odczytywania na czytnikach to przede wszystkim EPUB (ten format możesz odczytać m.in. na czytnikach PocketBook) i MOBI (ten fromat możesz odczytać m.in. na czytnikach Kindle).
Informacje na temat zabezpieczenia e-booka znajdziesz na karcie produktu w "Szczegółach na temat e-booka". Więcej informacji znajdziesz w dziale Pomoc.
czytaj
na smartfonie
Aby odczytywać e-booki na swoim smartfonie musisz zainstalować specjalną aplikację. W zależności od formatu e-booka oraz systemu operacyjnego, który jest zainstalowany na Twoim urządzeniu może to być np. iBooks dla EPUBa lub aplikacja Kindle dla formatu MOBI.
Informacje na temat zabezpieczenia e-booka znajdziesz na karcie produktu w "Szczegółach na temat e-booka". Więcej informacji znajdziesz w dziale Pomoc.
Czytaj fragment
Pobierz fragment
129,00
Najniższa cena z 30 dni: 129,00 zł

Wstrzykiwanie zależności - ebook

Wstrzykiwanie zależności. Zasady, praktyki, wzorce to poprawiona i rozszerzona wersja bestselleru Dependency Injection in .NET. Publikacja w sposób kompleksowy omawia zagadnienie wstrzykiwania zależności (DI). Zawiera przykłady, wzorce i antywzorce, które czytelnik może wykorzystać do tworzenia luźno powiązanych, dobrze zorganizowanych aplikacji. Szczegółowo opisany kod i diagramy wykorzystują przykłady w języku C# do zilustrowania zasad, które działają bezbłędnie z nowoczesnymi obiektowo-zorientowanymi językami programowania i bibliotekami DI.
W książce:
• refaktoryzacja istniejącego kodu w luźno powiązany kod,
• techniki DI działające z statycznie typowanymi językami zorientowanymi obiektowo,
• integracja ze znanymi frameworkami .NET,
• zaktualizowane przykłady ilustrujące wykorzystanie DI w .NET Core.
Publikacja przeznaczona dla średniozaawansowanych programistów OO.

Kategoria: Informatyka
Zabezpieczenie: Watermark
Watermark
Watermarkowanie polega na znakowaniu plików wewnątrz treści, dzięki czemu możliwe jest rozpoznanie unikatowej licencji transakcyjnej Użytkownika. E-książki zabezpieczone watermarkiem można odczytywać na wszystkich urządzeniach odtwarzających wybrany format (czytniki, tablety, smartfony). Nie ma również ograniczeń liczby licencji oraz istnieje możliwość swobodnego przenoszenia plików między urządzeniami. Pliki z watermarkiem są kompatybilne z popularnymi programami do odczytywania ebooków, jak np. Calibre oraz aplikacjami na urządzenia mobilne na takie platformy jak iOS oraz Android.
ISBN: 978-83-01-21396-1
Rozmiar pliku: 5,9 MB

FRAGMENT KSIĄŻKI

Recenzje pierwszego wydania

Realne przykłady pozwalają skupić się na tym co ważne… Prawdziwa gratka.

Glenn Block

Microsoft

Dobrze napisana, wnikliwa, łatwa do zastosowania i… ponadczasowa.

David Barkol

Neudesic

Zaspokaja wielką potrzebę dla projektantów .NET.

Paul Grebenc

PCA Services

Tłumaczy to co niewyjaśnione w tym temacie.

Rama Krishna

3C Software

Bardzo osobisty sposób, by dogłębnie nauczyć się współczesnych zasad rozwoju oprogramowania. Bardzo polecany!

Darren Neimke

HomeStart Finance

Wszystko, co musisz wiedzieć o wstrzykiwaniu zależności… i więcej!

Jonas Bandi

TechTalk

Lektura obowiązkowa na temat wstrzykiwania zależności.

Braj Panda

Capgemini India

Ta książka na pewno będzie kompletnym przewodnikiem do wstrzykiwania zależności w .NET.

Doug Ferguson

Improving Enterprise_przedmowa_

Istnieje osobliwy fenomen związany z Microsoftem, który nazywany jest _komorą pogłosową Microsoft._ Microsoft jest wielką organizacją, a przynależny ekosystem certyfikowanych partnerów Microsoftu zwiększa jeszcze tę wielkość o rzędy wielkości. Jeśli jest się mocno związanym z tym ekosystemem, może być ciężko zauważyć coś poza jego granicami. Zawsze, kiedy poszukuje się rozwiązania problemu z technologii lub produktu Microsoft, to prawdopodobnym rozwiązaniem będzie dorzucenie i wykorzystanie kolejnych produktów Microsoft. Nieważne, co wykrzyczy się w komorze pogłosowej, odpowiedzią jest _Microsoft_!

Ja (Mark) pracowałem przez lata dla certyfikowanych partnerów Microsoftu, więc kiedy zostałem zatrudniony przez sam Microsoft w 2003, byłem już od dawna osadzony w tej komorze. I przyznam, że ją uwielbiałem! Niedługo po moim zatrudnieniu wysłano mnie na wewnętrzną konferencję technologiczną do Nowego Orleanu. Miałem poznać najnowszą i najlepszą technologię Microsoftu.

Dzisiaj nie potrafię sobie przypomnieć ani jednej prelekcji dotyczącej produktów Microsoftu, w których brałem udział. Ale za to pamiętam ostatni dzień konferencji. Tego dnia głównie nie mogłem się doczekać lotu powrotnego do mojego domu w Danii, ponieważ żadna z prelekcji, na której byłem, nie mogła zaspokoić mojego głodu na ciekawą technologię. Moim priorytetem było znaleźć jakieś miejsce, gdzie mógłbym zająć się e-mailami. Dlatego wybrałem prelekcję, która wydawała mi się marginalnie istotna, i odpaliłem laptopa.

Prelekcja miała swobodną strukturę i brało w niej udział kilku mówców. Jednym z nich był brodaty facet, Martin Fowler, który opowiadał o Test-Driven Development (TDD) i o dynamic mocks. Nigdy wcześniej o nim nie słyszałem i też niezbyt uważnie go słuchałem, jednak coś musiało utkwić mi w głowie.

Niedługo po powrocie do Danii przydzielono mi zadanie przepisania dużego systemu ETL (extract, transform, load) od podstaw. Zdecydowałem się wypróbować TDD (okazało się to bardzo dobrą decyzją). Użycie dynamic mocks przyszło naturalnie jako kolejny etap, ale wskazało także potrzebę zarządzania zależnościami. Był to dla mnie bardzo trudny, ale i bardzo zajmujący problem, o którym nie mogłem przestać myśleć.

To, co rozpoczęło się jako efekt uboczny mojego zainteresowania TDD, stało się pasją samą w sobie. Zbierałem dużo informacji na ten temat, przeczytałem wiele wpisów blogowych, napisałem też kilka blogów sam, eksperymentowałem z kodem, a także rozmawiałem na ten temat z każdym, kto tylko chciał mnie słuchać. W coraz większym stopniu musiałem szukać inspiracji i wskazówek poza komorą pogłosową Microsoftu. W trakcie tych poszukiwań ludzie zaczęli kojarzyć mnie z ruchem ALT.NET, chociaż nigdy nie byłem w nim nazbyt aktywny. Popełniłem wszystkie błędy, których można było popełnić, ale wreszcie stopniowo byłem w stanie rozwinąć spójne zrozumienie Wstrzykiwania zależności (_Dependency Injection_, DI).

Kiedy wydawnictwo Manning po raz pierwszy skontaktowało się ze mną w sprawie książki na temat wstrzykiwania zależności w .NET, moja reakcja brzmiała „Czy to jest w ogóle potrzebne?”. Wydawało mi się, że wszystkie założenia/pojęcia, których twórca oprogramowania potrzebuje, by zrozumieć DI, zostały już opisane w wielu wpisach blogowych. Czy trzeba było cokolwiek dodawać? Naprawdę w moim odczuciu temat DI w .NET był już omówiony do granic możliwości.

Jednak po dłuższym zastanowieniu się olśniło mnie – wiedza na ten temat zdecydowanie jest dostępna, ale jest też bardzo rozproszona i wykorzystuje dużo sprzecznej terminologii. Przed pierwszym wydaniem tej książki nie istniały żadne publikacje o DI, które próbowałyby zaprezentować spójny opis tego zagadnienia. I kiedy pomyślałem o tym dogłębnie, uświadomiłem sobie, że Manning oferowało mi ogromne wyzwanie i niesamowitą możliwość do zebrania i usystematyzowania wszystkiego, co wiedziałem na temat DI.

Efektem jest ta książka oraz jej poprzednik – pierwsza edycja. Wykorzystano tu .NET Core i C# w celu przedstawienia pełnej terminologii, jak również wprowadzenia do DI, ale mam nadzieję, że wartość tej książki będzie mieć o wiele większy zasięg i dotrze poza platformę. W moim odczuciu język wzorców wyrażony na tych kartkach jest uniwersalny. I niezależnie od tego, czy jest się programistą .NET, czy używa się innej obiektowo-zorientowanej platformy, mam nadzieję, że ta książka pomoże komuś w byciu lepszym inżynierem oprogramowania._podziękowania_

Wdzięczność może wydawać się takim banałem, ale tylko dlatego, że jest to zasadnicza część ludzkiej natury. W trakcie pisania tej książki wielu ludzi dało nam powody, by być wdzięcznymi, i chcielibyśmy właśnie podziękować im wszystkim.

Po pierwsze, pisanie książki w naszym wolnym czasie pozwoliło nam zrozumieć, jak obciążający jest taki projekt dla naszego życia rodzinnego i małżeńskiego. Żona Marka, Cecilie, pozostała przy nim i aktywnie wspierała go w trakcie całego procesu tworzenia książki. Co najważniejsze, rozumiała, jak ważny to jest dla niego projekt. Nadal są razem, a Mark czeka z niecierpliwością na możliwość spędzenia więcej czasu z nią i ich dziećmi, Lineaą i Jarlem. Żona Stevena, Judith, dała mu przestrzeń potrzebną do ukończenia tak potężnego przedsięwzięcia, ale zdecydowanie jest zadowolona, że ten projekt wreszcie został zakończony.

W bardziej zawodowym kontekście, chcemy podziękować wydawnictwu Manning za daną nam możliwość. Inicjatorem projektu był Michael Stephens. Dan Maharry, Marina Michaels oraz Christina Taylor byli naszymi redaktorami i uważnie przyglądali się jakości tekstu. Pomogli nam w dostrzeżeniu słabszych punktów maszynopisu, a także udzielili nam obszernej konstruktywnej krytyki.

Karsten Strøbæk był naszym redaktorem technicznym. Przeczytał wiele wczesnych wersji tekstu i służył nam bardzo pomocnymi komentarzami. Karsten był także przy tym, gdy Mark napisał pierwszą edycję tej książki, i pomógł wtedy przy technicznej korekcie tekstu. W tej edycji korektę tekstu pod względem technicznym naniósł Chris Heneghan, który wyłapał dużo drobnych błędów i nieścisłości w całym tekście.

Po procesie pisania książki przeszliśmy do procesu jej produkcji. Ten etap był nadzorowany przez Anthony’ego Calcara, a redakcja tekstu przez Frances Buran, a wszystkim obrazom i diagramom w książce dokładnie przyglądała się Nichole Beard.

Chcielibyśmy podziękować z imienia i nazwiska wszystkim recenzentom, którzy w różnych stadiach powstawania tej książki udzielali nam swoich komentarzy i spostrzeżeń, a są to: Ajay Bhosale, Björn Nordblom, Cemre Mengu, Dennis Sellinger, Emanuele Origgi, Ernesto Cardenas Cangahuala, Gustavo Gomes, Igor Kochetov, Jeremy Caney, Justin Coulston, Mikkel Arentoft, Pasquale Zirpoli, Robert Morrison, Sergio Romero, Shawn Lam oraz Stephen Byrne. Recenzja książki była możliwa dzięki Ivanowi Martinovicowi, redaktorowi recenzji.

Wielu uczestników Manning Early Access Program (Programu wczesnego dostępu w wydawnictwie Manning) zapewniło nam feedback i postawiło dużo trudnych pytań, które odsłoniły słabe części tekstu.

Szczególne podziękowania kierujemy do Jeremy’ego Caneya, który zaczynał jako uczestnik Manning Early Access Program i dostał awans na recenzenta. Dostarczył nam ogromną ilość feedbacku zarówno w warstwie językowej, jak i kontekstualnej. Jego głębokie zrozumienie DI i projektowania oprogramowania jest nieocenione.

Kolejne szczególne podziękowanie należy się Ricowi Slappendelowi. Ric doradzał nam, jak utworzyć aplikacje UWP przy użyciu DI. Jego znajomość WPF, UWP oraz XAML oszczędziła nam niezliczonych godzin i nieprzespanych nocy. To jego porady w całości ukształtowały sekcję 7.2 i przykłady kodu towarzyszącego. Bez pomocy Rica książka prawdopodobnie nie zawierałaby wcale omówienia zagadnienia UWP.

Alex Meyer-Gleaves i Travis Illig recenzowali wczesne wersje rozdziału 13 i dostarczyli nam feedbacku na temat użycia nowej konfiguracji Autofacu i wsparcia Decoratora. Jesteśmy wdzięczni za ich udział.

I wreszcie Mogens Heller Grabe kurtuazyjnie pozwolił nam użyć jego zdjęcia suszarki do włosów podpiętej bezpośrednio do gniazdka!o książce

Przede wszystkim ta książka jest o Wstrzykiwaniu zależności (_Dependency Injection_, DI). Jest ona także o .NET, ale to mniej ważna część. I chociaż w przykładach kodu użyto C#, większość kwestii w tej książce może być łatwo zastosowanych w innych językach i na innych platformach. W rzeczywistości wiele podstawowych zasad i schematów poznaliśmy przez czytanie książek, w których w przykładach używano języków Java i C++.

DI jest zestawem pokrewnych wzorców i zasad. To bardziej sposób myślenia o kodzie i jego projektowania niż konkretna technologia. Ostatecznym celem wykorzystywania DI jest stworzenie utrzymywalnego oprogramowania w paradygmacie programowania obiektowego.

Wszystkie koncepcje wykorzystane w tej książce odnoszą się do programowania obiektowego. Problem, który DI rozwiązuje (utrzymywalny kod), jest uniwersalny, jednakże zaproponowane rozwiązanie jest podane w ramach zakresu programowania obiektowego w statycznie typowanych językach: C#, Java, Visual Basic, .NET, C++ itd. Nie można zastosować DI w programowaniu proceduralnym. DI może też nie być najlepszym rozwiązaniem dla języków funkcyjnych i dynamicznych.

DI samo w sobie to mały wzorzec, ale mocno wiąże się z wieloma zasadami i wzorcami obiektowego projektowania oprogramowania. Oprócz tego, że książka od początku do końca konsekwentnie skupia się na DI, omówiono w niej również te inne zagadnienia w świetle szczególnej perspektywy, którą umożliwia właśnie DI. Celem lektury jest więcej niż nauczenie specyfiki DI. To spowodowanie, że będzie się lepszym programistą obiektowym.

kto powinien przeczytać tę książkę?

Kuszące byłoby stwierdzenie, że jest to książka dla wszystkich programistów .NET. Ale obecnie społeczność .NET jest bardzo rozległa i dotyczy programistów pracujących z aplikacjami internetowymi, aplikacjami desktopowymi, mobilnymi, RIA, integracyjnymi, automatyką biurową, systemami zarządzania treścią, a nawet grami. Chociaż .NET jest obiektowy, to nie wszyscy jego programiści piszą kod obiektowy.

Ta książka jest o programowaniu obiektowym, więc chociaż w minimalnym stopniu jej czytelnicy powinni być zainteresowani aspektem obiektowym lub powinni rozumieć, czym jest interfejs. Na pewno przyda się kilka lat zawodowego doświadczenia, wiedza na temat wzorców projektowych lub też zasad SOLID. Tak naprawdę nie oczekujemy, że początkujący zrozumieją coś z tej książki; jest ona głównie skierowana do doświadczonych programistów i architektów oprogramowania.

Przykłady napisane zostały w języku C#, a więc czytelnicy pracujący z innymi językami .NET muszą potrafić czytać i rozumieć C#. Jednak osoby zaznajomione z różnymi językami obiektowymi spoza platformy .NET, takimi jak Java czy C++, mogą uznać tę książkę za wartościową. Dlaczego? Ponieważ treść charakterystyczna dla platformy .NET jest względnie lekka. Osobiście sami czytamy wiele książek o wzorcach z przykładami w Javie i dużo z nich zyskujemy, więc mamy nadzieję, że i ta pozycja będzie służyć nie tylko programistom .NET.

plan

Treść tej książki jest podzielona na cztery części. Idealnie byłoby przeczytać tę książkę od deski do deski, a potem używać jej jako odniesienia w swojej pracy, ale rozumiemy, że można mieć inne priorytety. Dlatego też większość rozdziałów została napisana tak, by móc w każdej chwili rozpocząć czytanie z dowolnego punktu.

Pierwsza część jest znaczącym wyjątkiem. Jest to ogólne wprowadzenie do DI i najlepsze byłoby czytanie tej części po kolei. Druga część to katalog wzorców i im podobnych, a trzecia największa część to przyjrzenie się DI pod trzema różnymi kątami. Czwarta część jest katalogiem trzech bibliotek będących kontenerami di.

W książce często będzie można znaleźć powiązane ze sobą pojęcia i w związku z tym niektóre terminy pojawiają się na długo przed wprowadzeniem swoich definicji. W skrócie napotyka się najpierw na sam termin, a dopiero za parę stron na jego definicję. Aby rozróżnić uniwersalne pojęcia od bardziej lokalnej terminologii, używamy wersalików, tak by łatwiej je wyróżnić w tekście. Wszystkie takie terminy są pobieżnie wytłumaczone w słowniczku pojęć, który składa się również z odniesień do bardziej obszernych opisów.

Część 1 jest ogólnym wprowadzeniem do DI. Jeśli ktoś nie ma wiedzy, czym jest DI, część I jest dobrym miejscem, aby rozpocząć lekturę. Ale nawet jeśli wie się, czym jest DI, można chcieć zaznajomić się z treścią tej części, gdyż pojawia się tam dużo terminologii i ugruntowuje ona kontekst zawarty w reszcie książki. W rozdziale 1 omówione zostają cel i korzyści DI, a także przedstawiony jest podstawowy zarys zagadnienia. W rozdziale 2 pojawia się obszerny i raczej rozległy przykład silnie powiązanego kodu, a w rozdziale 3 wytłumaczyliśmy, jak przekształcić i ponownie zaimplementować ten sam przykład, korzystając z DI. W porównaniu do innych części, część 1 ma bardziej linearny postęp w kwestii swojej treści. Najlepiej czytać każdy rozdział od początku, by zyskać z niego jak najwięcej.

Część 2 jest katalogiem wzorców, antywzorców i zapachów kodu. Tu znajdą się szczegółowe wskazówki, jak zaimplementować DI, oraz informacja o zagrożeniach, na które warto uważać. Rozdział 4 jest katalogiem wzorców projektowych Wstrzykiwania zależności, a rozdział 5 na odwrót – to katalog antywzorców. Rozdział 6 zawiera uogólnione rozwiązania dla często pojawiających się problemów. Tak jak w katalogu, każdy rozdział zawiera zbiór swobodnie powiązanych ze sobą sekcji, które zostały stworzone tak, by móc je czytać zarówno pojedynczo, jak i po kolei.

W części 3 analizujemy DI pod trzema różnymi kątami: kompozycji obiektowej, zarządzania cyklem życia (aplikacji) oraz przechwytywania. W rozdziale 7 omawiamy, jak zaimplementować DI na bazie już istniejących aplikacji opartych na ASP.NET Core i UWP, a także jak zaimplementować DI w aplikacji konsolowej.

W rozdziale 8 omawiamy, jak zarządzać cyklami życia zależności, tak by uniknąć wycieku zasobów. Znajduje się tu mniej ścisłą strukturę w porównaniu do wcześniejszych rozdziałów, ale za to duża część tego rozdziału może być wykorzystana jako katalog dobrze rozpoznanych cyklów życia. Trzy ostatnie rozdziały tej części skupiają się na tym, jak tworzyć aplikacje przy wykorzystaniu zagadnień przekrojowych. I tak rozdział 9 skupia się na podstawach przechwytywania przy użyciu Dekoratorów, a rozdziały 10 i 11 zagłębiają się w pojęciu programowania aspektowego. To w tym miejscu książki będzie można zauważyć wszystkie korzyści całej wcześniejszej pracy. Osobiście z wielu powodów uważamy to miejsce za najważniejsze w naszej książce.

Część 4 jest katalogiem bibliotek kontenerów di. Rozpoczynamy od omówienia, czym są kontenery di i w jaki sposób pasują one do całości. W trzech pozostałych rozdziałach prezentujemy indywidualnie i dość szczegółowo specjalne kontenery: Autofac, Simple Injector oraz Microsoft.Extensions.DependencyInjection. Każdy z rozdziałów wyjaśnia dany kontener raczej w skróconej wersji, by nie tracić miejsca. W związku z tym lepiej, gdyby ktoś przeczytał tylko o jednym lub dwóch kontenerach, które interesują go najbardziej. Te trzy ostatnie rozdziały w wielu kwestiach uważamy za jeden wielki zestaw załączników.

Aby omówienie zasad i schematów DI obyło się bez opierania się na API konkretnego kontenera, większość książki, z wyjątkiem części 4, została napisana bez odnoszenia się do jakiegokolwiek kontenera w szczególności. Dlatego też wymienione kontenery pojawiają się tak intensywnie w części 4. Mamy nadzieję, że właśnie przez utrzymanie dyskusji na poziomie ogólnym książka ta będzie przydatniejsza przez dłuższy czas.

Oczywiście można również użyć pojęć przewijających się od części 1 do części 3 i zastosować je w bibliotekach kontenerów nieopisanych w części 4. Istnieją naprawdę dobre kontenery, których, niestety, nie objaśniamy w tej książce. Niemniej jednak wierzymy, że ta książka może dużo zaoferować również użytkownikom nieopisanych przez nas kontenerów.

konwencja kodu i materiały do pobrania

Książka zawiera wiele przykładów kodu, w większości w C#, ale od czasu do czasu pojawia się też troszkę XML lub JSON. Kod źródłowy w listingach i tekście zapisany został czcionką o stałej szerokości, by odróżnić go od zwykłego tekstu.

Cały kod źródłowy w tej książce został napisany w C# i Visual Studio 2017. Aplikacje ASP.NET Core zostały napisane na podstawie ASP.NET Core v2.1.

Tylko niektóre z technik omówionych opierają się na nowych funkcjach języka. Chcieliśmy znaleźć równowagę między konserwatywnymi a nowoczesnymi stylami kodowania. Kiedy sami piszemy kod w życiu zawodowym, używamy nowoczesnych funkcji języka w o wiele wyższym stopniu, ale i tak w większości te najbardziej zaawansowane funkcje to typy parametryczne i LINQ. Nie chcemy, żeby ktoś sobie myślał, że DI może być używane jedynie z supernowoczesnymi językami.

Napisanie przykładów kodu dla jakiejkolwiek książki to wyzwanie samo w sobie. W porównaniu do dzisiejszych ekranów komputerów, książka pozwala jedynie na bardzo krótkie linijki kodu. Bardzo kusząca była myśl napisania kodu w lakonicznym stylu, gdzie metody i zmienne przyjęłyby krótkie i zagadkowe nazwy. Taki kod w prawdziwym życiu jest już trudny do zrozumienia, nawet jeśli używa się IDE i debuggera. Więc co tu mówić o nadążeniu za nim na papierze. Stwierdziliśmy, że ważne jest, aby nazwy były tak czytelne jak to tylko możliwe. Czasami musieliśmy się uciec do nieortodoksyjnych metod podziału linijek. Cały kod jest kompilowalny, ale czasami jego formatowanie wygląda trochę dziwacznie.

Kod wykorzystuje również słowo kluczowe var z języka C#. Podczas naszej pracy, kiedy szerokość linijki nie jest ograniczona stroną książki, często wykorzystujemy różne style kodowania w trakcie stosowania var. Na potrzeby tej publikacji, by oszczędzić miejsca, używamy var wtedy, kiedy sądzimy, że użycie pełnej deklaracji typu powoduje mniejszą czytelność kodu.

Słowo _klasa_ jest często używane jako synonim słowa typ. W .NET, klasy, struktury, interfejsy, typy wyliczeniowe itd. to wszystko typy, ale ponieważ słowo _typ_ jest przesycone różnymi znaczeniami w zwykłym języku, częste jego użycie powodowałoby niejasności.

Większość kodu w tej książce odnosi się do nadrzędnego przykładu przewijającego się przez rozdziały: sklep internetowy uzupełniony o wewnętrzne aplikacje zarządzające. Jest to chyba najmniej wymyślny przykład, jaki można znaleźć w jakimkolwiek tekście o oprogramowaniu, ale wybraliśmy go z m.in. dwóch powodów:

1. ■ jest to dobrze znany problem domeny dla większości czytelników. Mimo że może wydawać się on nudny, uważamy to za jego plus – nie odciąga on uwagi od najważniejszej kwestii, czyli DI.
2. ■ Ponadto musimy się przyznać, że nie mogliśmy wymyślić żadnej innej domeny, która byłaby na tyle złożona i pozwoliła na wykorzystanie w tych wszystkich różnych aspektach, które stworzyliśmy w naszych głowach.

Napisaliśmy naprawdę dużo kodu na poparcie tych przykładów, ale większość nie trafiła nawet do książki. Tak naprawdę napisaliśmy prawie cały kod na bazie Test-Driven Development (TDD), ale jako że nie jest to praca o TDD, to w zasadzie nie pokazujemy tu testów jednostkowych.

Kod źródłowy dla wszystkich przykładów zamieszczonych w tej książce jest dostępny na stronie wydawnictwa Manning: www.manning.com/books/dependency-injection-principles-practices-patterns.

Plik README.md w pobranym katalogu zawiera instrukcje do kompilacji i uruchomienia kodu.

forum dyskusyjne livebook

Wraz z zakupem _Wstrzykiwanie zależności. Zasady, praktyki, wzorce_ otrzymuje się darmowy dostęp do prywatnego forum internetowego zarządzanego przez Manning Publications. Można tam dodawać komentarze na temat książki, zadawać techniczne pytania i otrzymać pomoc od samych autorów oraz innych użytkowników forum. Aby otrzymać prawo dostępu i subskrypcję, wystarczy wpisać adres https://livebook.manning.com/book/dependency-injection-principles-practices-%20patterns/discussion. Można również dowiedzieć się więcej o forum wydawnictwa i zasadach postępowania pod adresem https://livebook.manning.com/discussion.

Wydawnictwo Manning udostępnia platformę do konstruktywnego dialogu zarówno między samymi czytelnikami, jak i między czytelnikami a autorami. Jednak autorzy nie zobowiązują się do określonego w jakikolwiek sposób uczestnictwa, jako że ich udział na forum jest dobrowolny (i bezpłatny). Sugerujemy zadawanie trudnych i wymagających pytań, inaczej nie będą zainteresowani! Forum książki oraz archiwum wszystkich dyskusji będą dostępne na stronie wydawcy tak długo, jak książka pozostanie w druku i będzie pojawiać się jej reedycja._o autorach_

Steven van Deursen jest Duńczykiem. Pracuje jako niezależny programista .NET oraz architekt. Swoją karierę zawodową w tej dziedzinie rozpoczął w 2002 roku. Mieszka w Nijmegen i lubi pisać kod zarówno dla zabawy, jak i dla zarobku. Oprócz pisania kodu w wolnym czasie Steven trenuje sztuki walki, lubi zjeść na mieście i zdecydowanie ma słabość do dobrej whisky.

Mark Seemann jest programistą, architektem oprogramowania i wykładowcą mieszkającym w Kopenhadze. Pracuje z oprogramowaniem od 1995, a z TDD od 2003 roku, w tym przez 6 lat był konsultantem, programistą i architektem dla Microsoftu. Obecnie Mark zawodowo zajmuje się rozwojem oprogramowania i pracuje zdalnie z Kopenhagi. Lubi czytać, malować, grać na gitarze, pić wino i jeść wyszukane dania.o ilustracji na okładce

Na okładce _Wstrzykiwania zależności. Zasady, praktyki, wzorce_ zaprezentowano „Kobietę z Vodnjan” (_A woman from Vodnjan_) – Vodnjan to małe miasteczko w środkowej części chorwackiego półwyspu Istria na Morzu Adriatyckim. Ilustrację zaczerpnięto z reprodukcji albumu tradycyjnych chorwackich strojów z połowy XIX w. Reprodukcja została stworzona przez Nikola Arsenovica i wydana przez Muzeum Etnograficzne w Splicie, w Chorwacji w 2003 roku. Ilustracje otrzymano dzięki uprzejmemu bibliotekarzowi Muzeum Etnograficznego w Splicie. Samo muzeum usytuowane jest w rzymskiej części średniowiecznego centrum miasta: ruinach rezydencji rzymskiego cesarza Dioklecjana z około 304 r.n.e. W książce można znaleźć piękne ilustracje postaci z różnych regionów Chorwacji. Każdemu obrazkowi towarzyszy opis stroju oraz codziennego życia w tej epoce. Vodnjan jest kulturowo i historycznie ważnym miastem usytuowanym na wzgórzu. Pod miastem rozciąga się piękny widok Adriatyku, a samo Vodnjan znane jest z wielu kościołów i skarbów sztuki sakralnej. Kobieta na okładce książki ma na sobie długą czarną lnianą spódnicę oraz krótki czarny żakiet, spod którego wystaje biała lniana koszula. Żakiet zakończony jest niebieskim haftem. Niebieski lniany fartuszek dopełnia całego stroju. Kobieta ma także na głowie czarny kapelusz z dużym rondem, na szyi apaszkę w kwiatki, natomiast w uszach duże kolczyki koła. Jej elegancki strój wskazuje na to, że jest mieszczanką, a nie wieśniaczką. Stroje ludowe z tych okolic są bardziej kolorowe, wykonane z wełny i przyozdobione bogatymi haftami.

Ubiór i styl życia zmieniły się przez 200 lat, a różnorodność regionu, tak bujna w tamtych czasach, powoli odeszła w niepamięć. Dzisiaj trudno odróżnić mieszkańców różnych kontynentów, a co dopiero różnych osad i miasteczek położonych w odległości kilku mil od siebie. Możliwe, że różnorodność kulturową zamieniliśmy na bardziej zróżnicowane życie osobiste. Na pewno zamieniliśmy ją na bardziej zróżnicowane i dynamiczne życie technologiczne.

Wydawnictwo Manning docenia innowacyjność i inicjatywę przemysłu komputerowego za pomocą okładek, które prezentują bogatą różnorodność życia regionalnego sprzed dwóch wieków. Ta różnobarwność jest przywracana do życia przez ilustracje z zabytkowych książek i kolekcji takich jak ta okładka._CZĘŚĆ 1_.
UMIEJSCOWIENIE WSTRZYKIWANIA ZALEŻNOŚCI NA MAPIE

Wstrzykiwanie zależności (_Dependency Injection_, DI) jest jednym z najbardziej niezrozumiałych pojęć programowania obiektowego. Niejasności są liczne i obejmują: terminologię, cel i mechanizmy. Może powinniśmy nazywać ten wzorzec Wstrzykiwaniem zależności, Inwersją zależności, Odwróceniem sterowania albo nawet Połączeniem trzeciej strony? Czy celem DI jest tylko wsparcie testów jednostkowych, czy może istnieje jego szersze zastosowanie? Czy DI to lokalizacja usług? Czy potrzebujemy kontenerów di w celu zastosowana DI?

Powstało wiele wpisów blogowych, artykułów w magazynach, prezentacji podczas rozmaitych konferencji itp., które omawiały DI, ale niestety w wielu użyto sprzecznej terminologii i podzielono się złymi poradami. Klapa na całej linii. Nawet ci duzi i wpływowi na rynku, tak jak Microsoft, dorzucają swoje do tych niejasności.

Tak nie musi być. W tej książce konsekwentnie prezentujemy i używamy stałej terminologii. W większości zaadaptowaliśmy i objaśniliśmy istniejące już pojęcia, które stworzyli inni przed nami, ale czasami dodaliśmy odrobinę terminologii, której wcześniej nikt nie używał. To znacząco pomogło nam w rozwinięciu specyfikacji zakresu oraz granic DI.

Jednym z powodów takiej niespójności i nietrafionych porad jest fakt, że granice DI są dość nieoczywiste. Gdzie kończy się DI, a zaczynają inne obiektowe pojęcia? Naszym zdaniem niemożliwe jest oddzielenie wyraźną linią DI od innych aspektów tworzenia dobrego kodu obiektowego. Omawiając DI, nie możemy nie przywołać innych pojęć, takich jak: SOLID, Czysty kod, a nawet programowanie aspektowe. W naszym odczuciu nie można wiarygodnie opisać DI bez uwzględnienia niektórych ze wspomnianych tematów.

Pierwsza część tej książki pomoże w zrozumieniu, gdzie znajduje się DI w odniesieniu do innych aspektów inżynierii oprogramowania – w pewnym sensie chodzi o umiejscowienie wzorca na mapie. Rozdział 1 jest krótkim przewodnikiem po DI, gdzie opisany jest jego cel, zasady oraz korzyści. To również zarys zakresu reszty książki. W tym rozdziale skupiamy się na ogóle i nie wchodzimy zbytnio w szczegóły. Jeśli ktoś chce dowiedzieć się, czym jest DI i dlaczego powinien się nim interesować, to dobre miejsce, by zacząć czytać. Do rozdziału 1 nie potrzeba jakiejkolwiek wcześniejszej wiedzy na temat DI. A nawet jeśli już coś się wie o tym wzorcu, nadal warto pochylić się nad tym tekstem – może się okazać, że DI to coś całkiem innego, niż się wydawało.

Odnośnie do rozdziału 2 i 3 – są one w całości zarezerwowane i poświęcone jednemu dużemu przykładowi, którego zadaniem jest konkretniejsze wyczucie wzorca DI. W rozdziale 2 ukazaliśmy typową silnie powiązaną implementację przykładowej aplikacji e-commerce – bardziej tradycyjny styl programowania, który mocno kontrastuje z DI. Następnie, w rozdziale 3, ten sam przykład jest zaimplementowany ponownie przy użyciu DI.

W tej części omówimy DI na zasadach ogólnych. Oznacza to, że nie będziemy wykorzystywać żadnych tak zwanych kontenerów di. Istnieje możliwość pełnego zastosowania DI bez żadnego kontenera di, jako że jest to przydatne, ale wciąż opcjonalne, narzędzie. W związku z tym części 1, 2 oraz 3 pomijają mniej więcej w całości kontenery di i skupiają się na DI w kontekście niezależnym od kontenerów. Dopiero w części 4 powracamy do kontenerów di, by przeanalizować trzy specyficzne biblioteki.

Część 1 nadaje kontekst całej książce. Stworzona została w tej formie dla czytelników, którzy nie mieli wcześniej styczności z DI, ale doświadczeni użytkownicy tego wzorca mogą również skorzystać z tych rozdziałów, by zapoznać się z terminologią przewijającą się w całej książce. Pod koniec części 1 każdy powinien mieć gruntowną wiedzę na temat słownictwa i ogólnych pojęć, nawet jeśli niektóre ze szczegółów mogą nadal wydawać się troszkę niejasne. Takie odczucie jest w porządku, ponieważ książka staje się coraz bardziej konkretna z każdym kolejnym przeczytanym rozdziałem. A więc części 2, 3 i 4 powinny rozwiać wszelkie wątpliwości i odpowiedzieć na pytania, które pewnie pojawią się po przeczytaniu części 1.PRZYPISY

Rozdział 1

1 Zob. J. Munsch et al. (2009), _How to explain Dependency Injection to a 5-year old?_ . Dostęp: https://stackoverflow.com/questions/1638919/how-to-explain-dependency-injection-to-a-5-year-old.

2 E. Gamma et al., _Design Patterns: Elements of Reusable Object-Oriented Software_, Addison–Wesley, 1994, 18. Polskie tłumaczenie: _Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku_, Helion, 2010.

3 E. Gamma et al., _op.cit.,_ 87.

4 W pierwszej edycji tej książki „Wstrzykiwanie zależności w .NET” (Dependency Injection in .NET) wykorzystaliśmy termin DI _biednego człowieka_. czyste di zastąpiło ten termin, ale niech nikogo nie zdziwi stary zwrot w Internecie. Dlaczego zmieniliśmy terminologię, zob. M. Seemann (2014). _Pure_ DI . Dostęp: https://blog.ploeh.dk/2014/06/10/pure-di/.

5 E. Gamma et al., _op.cit.,_ 175.

6 E. Gamma et al., _op.cit.,_ 163.

7 E. Gamma et al., _op.cit.,_ 139.

8 M. Fowler et al., _Refactoring: Improving the Design of Existing Code_, Addison–Wesley, 1999, 250. Polskie tłumaczenie: _Refaktoryzacja. Ulepszanie struktury istniejącego kodu_, Helion, 2011.

9 M. Fowler (2005). _Event Sourcing_ . Dostęp: https://martinfowler.com/eaaDev/EventSourcing.html.

10 Klasa System.Security.Principal.WindowsIdentity znajduje się w pakiecie NuGet System.Security.Principal.Windows, który jest częścią .NET Core.

11 M.C. Feathers, _Working Effectively with Legacy Code,_ Prentice Hall 2004, xvi. Polskie tłumaczenie: _Praca z zastanym kodem. Najlepsze techniki_, Helion 2014.

12 G. Meszaros, _xUnit Test Patterns: Refactoring Test Code_, Addison–Wesley 2007, 522.

13 Jednak warto przeczytać _The Art. Of Unit Testing_ Roya Osherove’a (polskie tłumaczenie: _Testy jednostkowe. Świat niezawodnych aplikacji._ Wydanie II, __ Helion 2014), a następnie _xUnit Test Patterns_ Gerarda Meszarosa (_op. cit._).

14 Obiekt typu Spy jest obiektem typu Test Double, który wychwytuje pośrednie odwołania do innego komponentu przez SUT dla późniejszej weryfikacji przez test. Zob. G. Meszaros, _op.cit.,_ 538.

15 M.C. Feathers, _op.cit.,_ 29–44.
mniej..

BESTSELLERY

Kategorie: