nblog

M-V-P Twoim przyjacielem

Będąc na studiach zacząłem pracę programisty. Głowę miałem wypakowaną teorią, a w duszy grała chęć zastosowania tego wszystkiego w praktyce. Każdy kto czytał o wzorcach projektowych GoF wie jak bardzo zmienia ona postrzeganie i jak bardzo zachęca nas do wykorzystywania tychże wzorców w praktyce. Niestety od nadmiaru wzorców głowa boli. Pewne mało skomplikowane aplikacje zupełnie ich nie potrzebują, a wprowadzenie ich tylko niepotrzebnie zaciemnia obraz sytuacji. Zatem wybór wzorca i to, czy rzeczywiście jego zastosowanie ma sens, poprzeć trzeba pewnym uzasadnieniem.

Zaczynając pracę trafiłem do zespołu, który buduje aplikację w oparciu o Windows Forms, znaczy się to co tygryski lubią najbardziej. Już na samą myśl o WF w głowie zapala mi się lampka - MVP. Wcześniej nie miałem okazji wypróbować go w boju. W małych projektach studenckich stosowałem, ale z rzeczywistych jego możliwości nigdy nie korzystałem. Co więcej, nie do końca zdawałem sobie sprawy z jego potęgi!

W tekście tym chciałem Wam opowiedzieć o tym jak na co dzień wykorzystuję ten wzorzec i jakie wymierne korzyści dzięki niemu uzyskałem.

Grunt to dobry podział

Dla wielu implementacja wzorca MVP sprowadza się do tego, że będą mogli podmieniać widoki. Casami ludzie mówiąc o zaletach MVP wskazują na to, że można tak napisać aplikację wykorzystując ten wzorzec, że będzie można wymiennie stosować Windows Forms oraz ASP.Net. Jakoś nie widziałem, żeby się to komuś udało. Nie twierdzę że nie jest to możliwe, ale czy rzeczywiście o to chodzi?

Spójrzmy może na ten wzorzec z innej strony. Wprowadza on podział na trzy elementy: Model, Widok i Prezentera. Zapytać ktoś może po co taki podział? Czemu nie mogę oprogramować okna w jego klasie? Nie mając perspektyw dalszego rozwoju aplikacji moglibyśmy tak zrobić, jednak praktyka sugeruje, że aplikacja będzie rosła a klient będzie wymyślał nowe problemy do rozwiązania.

Przede wszystkim oddziel zagadnienia (ang. Separation of Concerns, SoC). Wprowadzenie tych trzech elementów nie jest przypadkowe. Widok to reprezentacja wizualna danych – która może mieć wiele postaci np. okno czy strona www. Prezenter to logika reprezentacji danych. Definiuje zachowanie widoku np. reaguje na akcje użytkownika. Na końcu model to dane. Czasami danymi jest pojedynczy obiekt, innym razem może to być zbiór obiektów. Promując zasadę SoC rozdzielamy te zagadnienia umieszczając je w osobnych klasach.

Podmiany

Dobrze, mamy już jakieś wymierne korzyści, które w dowolnej wielkości aplikacji będą procentować. Zastanówmy się teraz jak z tego wzorca wyciągnąć jeszcze więcej. W pracy niejednokrotnie spotkałem się z problemem ponownego wykorzystania komponentów. Weźmy mały przykład, który z powodzeniem odnajdziecie w wielu rozwiązaniach klasy ERP, CRM lub podobnych. Chodzi mi o listę kontrahentów. Z pozoru problem jest prosty – należy umożliwić zarządzanie kontrahentami w aplikacji. Sprowadza się to do zaimplementowania listy kontrahentów, a także szczegółów konkretnego kontrahenta. Skupmy się jednak na samej liście. Zadanie banalne – mamy tabelę w bazie danych zawierającą dane o kontrahentach. Nasza lista będzie pobierała wszystkie dane z tej tabeli i wyświetlała w tabeli w oknie programu.

Mija czas i przychodzi następne wymaganie. Należy umożliwić wybór kontrahenta z listy. Sytuacja dotyczy wszystkich dokumentów handlowych aplikacji, w których trzeba wybrać kontrahenta. Oczywiście system musi być spójny więc lista musi wyglądać i zachowywać się identycznie (możliwość dodawania, edycji itd.). Zabieramy się za implementację. Tę samą formatkę wzbogacamy o właściwość IsInSelectionMode, którą ustawiać będziemy na true, gdy będziemy wyświetlać listę w trybie wyboru. Wewnątrz dodajemy odpowiednie if-y, aby zmienić działanie formatki np. jednym z wymagań jest to, aby dwuklik na wierszu powodował wybór w trybie wyboru, a edycję w trybie zwykłym. Wszystko śmiga.

Znów mija trochę czasu. Przychodzi klient i mówi: jak wpiszę tylko część nazwy klienta a w bazie jest więcej niż jeden klient o nazwie zaczynającej się na wpisaną frazę to chcę aby pojawiła się lista klientów zawężona tylko do tych pasujących do frazy. Znów przystępujemy do implementacji. Gdy użytkownik wpisze żądaną frazę strzelamy do bazy i mamy już listę pasujących kontrahentów. Zgodnie z warunkiem, jeżeli jest ich więcej niż jeden otwieramy listę. Sama lista też wymaga pewnych modyfikacji. Mając zestaw danych w ręce (listę pasujących kontrahentów) nie chcemy aby lista sama pobierała dane, tylko chcemy jej podać to co już mamy. Dodajemy kolejne pole i przypisujemy mu zawartość listy kontrahentów zaczynających się od frazy. W samej liście znów dodajemy if-y, tak aby spełnić wymagania. Teraz jeżeli nowo dodane pole nie jest puste nie pobieramy wszystkich kontrahentów z bazy, a jedynie wyświetlamy tych otrzymanych.

Spoglądając wstecz zauważymy, że stworzyliśmy coś, co na dłuższą metę może być uciążliwe w utrzymaniu. Nie dość, że wszystkie funkcje dotyczące obsługi listy są w jednej klasie to jeszcze sama logika się skomplikowała, ponieważ wprowadzono warunki if. Każda z komend dotycząca zawartości wyświetlanej listy np. ‘odśwież’ musiała zostać odpowiednio zmodyfikowana, aby zapewnić poprawność, bo przecież nie możemy pobierać danych z bazy danych mając zadaną stałą listę. To prowadzi do większego prawdopodobieństwa popełnienie błędu, albo wprowadzenia błędu przy późniejszych modyfikacjach.

Co więcej z punktu widzenia programisty, który naszej listy będzie używał, jej API nie do końca jest intuicyjne. Musi wiedzieć, że właściwość IsInSelectMode przełącza listę w tryb wyboru, a ustawienie pola ExternalDataSource powoduje zmianę zachowania listy i wyświetlenie tylko zadanego zestawu danych.

Rozwiązanie takie tworzy wiele problemów. Nie ma jasno powiedziane gdzie znajduje się źródło danych. Informacja ta jest rozproszona po kodzie całej kontrolki. Nie ma też jasno określonego dostawcy danych. Lista w standardowym trybie sama zaczytuje sobie dane, ale w przypadku trybu zawężonej listy, dane pobierane są z zewnątrz.

Z punktu widzenia utrzymania takiego komponentu mamy kolejny problem. Promując zasadę otwarty-zamknięty (ang. Open-Closed Principle, OCP) chcielibyśmy, aby dodawanie nowych funkcji mogło się odbyć bez modyfikacji już istniejących klas. W tym wypadku dodanie kolejnego trybu (a nie zdziwiłbym się, gdyby poproszono o coś jeszcze) wiąże się z nieustannym modyfikowaniem tej samej klasy, która szybko przyjmie rozmiary kilku tysięcy linii kodu.

W tym przypadku i wielu innych, które spotkałem podczas pracy z pomocą przyszedł mi wzorzec MVP i podział wprowadzany przez jego komponenty. Tak jak pisałem wcześniej Prezenter określa nam klasę odpowiedzialną za zachowanie, a model dostarcza danych. Z powodzeniem możemy wykorzystać te klasy jako elementy wymienne.

Zobaczmy jak takie rozwiązanie mogłoby wyglądać. W tekście wytłuściłem elementy opisujące kolejne wymagania. Pierwsza zmiana polegała na zmianie zachowania formatki. Skoro zmienialiśmy zachowanie to w modelu MVP wystarczyłoby wymienić prezentera na takiego, który definiuje odrębne zachowanie. Wystarczyłoby mieć bazowego prezentera, który obsługuje wszystkie wspólne komendy takie jak dodawanie i usuwanie, a dwa dziedziczące po nim definiowały by obsługę dwukliku. Prawda, że proste?

Drugie wymaganie polegała na zmianie danych wyświetlanych na liście. Dlaczego nie wyodrębnić dwóch modeli. Pierwszy obsługiwałby wersję standardową wczytując wszystkich kontrahentów z bazy danych, a drugi przyjmowałby w konstruktorze gotowy zestaw danych. Prawda, że proste?

Teraz uruchomienie listy w żądanym trybie sprowadza się do wyboru odpowiedniego prezentera oraz odpowiedniego modelu. Na przykład chcąc uruchomić listę w trybie wyboru z zawężoną listą kontrahentów napisalibyśmy:

1 var view = new CustomerListView();
2 var model = new ManualCustomerListModel(matchingCustomers);
3 var presenter = new CustomerSelectionPresenter(view, model);

Oczywiście nie moglibyśmy tego osiągnąć gdyby nie to, że każdy z tych komponentów opisany został dobrze określonym interfejsem. Dzięki temu całą trójkę możemy dowolnie komponować.

Wspomniałem wcześniej, że pierwsze rozwiązanie w ogóle nie spełnia zasady otwarty-zamknięty. Zobaczmy jaką sytuację mamy teraz. Każda z wariacji na temat listy kontrahentów zamknięta została w swojej własnej klasie. Zaimplementowanie kolejnego przypadku sprowadza się teraz do rozważenia jakie własności są modyfikowane. Jeżeli modyfikujemy zachowania to należy odpowiednio zaimplementować prezentera. Natomiast jeżeli modyfikujemy wyświetlane dane wprowadzamy nową implementację modelu. Co ważne to to, że nawet przez chwilę nie dotykamy klas już istniejących.

Podsumowanie

Przedstawiony tutaj problem dotyczący listy kontrahentów jest oczywiście dość prostym przypadkiem. W rzeczywistości spotkałem się z sytuacjami, gdzie zachowanie okna znacznie się różniło od jego podstawowej implementacji. Tak samo było z danymi. Nie implementowałem natomiast nigdy dwóch widoków mających prezentować wspólne dane, ale jak łatwo się domyślić nie powinno to nastręczać problemów przy zachowaniu jednolitego interfejsu.

Ci, którym nie jest obojętna wysoka jakość systemu zauważą, że implementacja testów jednostkowych dla tak zdefiniowanego systemu, nie powinna być skomplikowana. Projektując w ten sposób sprawiamy, że system jest testowalny.

Z własnych praktycznych doświadczeń mogę szczerze powiedzieć, że zastosowanie wzorca MVP oszczędziło mi wiele pracy, oszczędza i będzie oszczędzało w przyszłości, gdy przyjdzie mi rozszerzać bądź poprawiać błędy. Mając odpowiedni podział możemy dowolnie manipulować jego podzespołami, wymieniając je wedle uznania i komponując co raz to nowe rozwiązania. Tak zaprojektowany system jest niesamowicie elastyczny, zgodny z zasadą OCP, dzięki czemu daje się łatwo utrzymywać.

Dobrze określony podział obowiązków pozwala nam szybciej i bardziej mechanicznie podejmować decyzje o tym gdzie dana funkcja powinna się znaleźć. Znając naturę dużych i skomplikowanych systemów wiem, że implementacja jednej formatki może nam urosnąć do kilku tysięcy linii kodu. Dzięki podziałowi możemy tą ilość podzielić.

Moja implementacja tego wzorca cały czas ewoluuje. Oparłem ją na wzorcach, które zdefiniował Martin Fowler. Passive View definiuje widok jako reprezentację graficzną, która jest „głupia” jeżeli chodzi o obsługę komend i do tego celu wykorzystuje prezentera. Supervising Controller określa prezentera jako sterownik, który odbiera komendy od widoku i zawiaduje całą logiką. Moją implementację staram się cały czas ulepszać. Jeżeli jeszcze tego nie robicie to zachęcam Was do eksperymentów i zaadaptowania tego wzorca. Zapewniam, że włożony w to wysiłek na pewno się zwróci. Na początku może się to wydawać niepotrzebnie skomplikowane i na wyrost, ale wraz z wzrostem systemu dostrzeżecie zalety.

Wtyczki do ReSharper 4.x – Odc. 2 – Przygotowanie środowiska

Przygodę z tworzeniem wtyczek zaczniemy od przygotowania środowiska programistycznego. Przede wszystkim potrzebna jest nam instalacja samego R#, bo to jego biblioteki są dla nas podstawą. Z tego co zauważyłem to R# nie ma osobnych bibliotek w stylu SDK. Tworząc wtyczki będziemy odwoływali się do tych bibliotek, które będą nam potrzebne.

Wtyczka dla ReSharpera to biblioteka DLL. W jednej bibliotece może znajdować się tylko jeden plugin. R# potrafi współpracować z wtyczkami napisanymi dla .Net 3.5 jak również 2.0. Zacząć należy od utworzenia projektu biblioteki (Windows Class Library). Następnie nowo powstały projekt konfigurujemy, aby móc w prosty sposób testować rozwijaną wtyczkę.

W opcjach projektu ustawiamy, aby przy wywołaniu debugowania uruchamiał się zewnętrzny program z odpowiednimi parametrami w lini poleceń. Oczywiście tym programem będzie Visual Studio jako że to w nim będzie osadzona nasza wtyczka. Do rejestracji wtyczki w R# na czas debugowania służy przełącznik:

/ReSharper.Plugin "ścieżka do pliku DLL wtyczki"

Całość może wyglądać tak: c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe /ReSharper.Plugin "D:\projekty\ResharperPrugins\SampleResharperPlugin\bin\Debug\SampleResharperPlugin.dll”. Dzięki tym ustawieniom będziemy mogli debugować rozwiązanie w Visual Studio.

Rys. 1. Konfiguracja opcji debugowania

Drugim krokiem jest przygotowanie samej wtyczki tak, aby R# mógł ją odpowiednio rozpoznać. Do tego celu służą atrybuty, które możemy umieścić w pliku AssemblyInfo.cs. Aby móc z nich skorzystać musimy dodać referencję do pliku JetBrains.Platform.ReSharper.UI.dll. Do opisu wtyczki służą atrybuty: PluginTitleAttribute, PluginDescription, PluginVendor. Myślę, że ich nazwy mówią same za siebie. Każdy z nich przyjmuje jako parametr napis określający odpowiednią wartość. Przykładowe użycie może wyglądać tak:

  1 [assembly: PluginTitle("Szarpnięty!")]
  2 [assembly: PluginDescription("Wyszarpana wtyczka")]
  3 [assembly: PluginVendor("Bartłomiej Legiędź")]

Teraz wciskając F5 po raz pierwszy uruchomimy swoją własną wtyczkę do R#. Chwilowo zignorujemy fakt, że ta wtyczka nic nie robi. Zadowolimy się tym, że R# już o niej wie.

 
Rys. 2. Wtyczka została rozpoznana i załadowana

Podsumowując, przygotowanie środowiska jest proste i zamyka się w następujących krokach:

1. Tworzymy projekt Windows Class Library
2. Konfigurujemy opcje debugowania
3. Dodajemy referencję do JetBrains.Platform.ReSharper.UI.dll
4. Dodajemy atrybuty opisujące wtyczkę (nazwa, opis, producent)
5. Wciskamy F5 by sprawdzić, czy wtyczka poprawnie się ładuje

Dla leniwców przygotowałem mały wzorzec projektu dla Visual Studio. Dołączone do postu archiwum wystarczy skopiować do katalogu z wzorcami projektów (domyślnie: c:\Documents and Settings\<user>\Moje dokumenty\Visual Studio 2008\Templates\ProjectTemplates\Visual C#\) i VS pozwoli nam z tego wzorca skorzystać. Zawarłem w nim referencję do biblioteki R# zawierającej atrybuty wtyczki, a w pliku AssemblyInfo.cs umieściłem te atrybuty z pustymi wartościami.

Spis treści:

1. Wprowadzenie
2. Przygotowanie środowiska (ten tekst)
3. ... (dalej zobaczymy, dopiero poznaję zagadnienie)

Wtyczki do ReSharper 4.x – Odc. 1 – Wprowadzenie

Będąc jeszcze na studiach byłem na jednym z seminariów, które prowadził mój kolega z roku niżej. Podczas prezentacji pisał kod ‘na żywo’. Nie dość, że i tak już szybko pisał na klawiaturze to okazało się, że używa jeszcze jakichś czarodziejskich sztuczek. W oknie edytora pojawiały się jakieś dziwne kółka i strzałki. Po westchnięciach sali przerwał i przedstawił narzędzie. Był to dodatek do Visual Studio - CodeRush + Refactor! Pro. Był to rok 2004.

Po zainstalowaniu tego narzędzia szybko okazało się, że mój komputer sobie z nim nie poradzi. Jeszcze tego samego dnia odinstalowałem je i trochę zawiedziony usiadłem do ‘starego’ Visual Studio. W między czasie pojawiały się nowe wersje, a także konkurencja (nie wiem co było pierwsze Refactor! czy ReSharper, ale to nie ważne). Faktem jest, że nie zawracałem sobie nimi głowy, bo po co przyzwyczajać się do jakiegoś narzędzia, na które mnie nie stać i które po 30 dniach trzeba będzie odinstalować...

Jednak ostatnio ReSharper znów wpadł mi w ręce. Pojawiły się nocne buildy i przez dłuższy okres czasu można było mieć go za darmo. Spróbowałem i okazało się, że po kupnie dodatkowego 1Gb ramu (po tym w sumie mam 2Gb) mogę spokojnie z nim pracować. Okazało się też, że po tygodniu współpracy już nie mogłem bez niego żyć ;)

I został ReSharper. Jestem z niego bardzo zadowolony. Z jednej strony traktuję to narzędzie jako programistyczny dopalacz, który przyspiesza moją pracę. Z drugiej jednak strony wydaje się on użytecznym zamiennikiem API, którego dostarcza nam Visual Studio. W serii artykułów chciałbym Wam przybliżyć Open API, którego dostarcza ReSharper. Osobiście widzę w tym narzędziu wielki potencjał. Kolejnymi artykułami chciałbym zachęcić Was do tego, aby ten potencjał wyokorzystać. Nadmienić należy również, że wiele funkcji ReSharpera jest pisana tak jak dodatki, czyli przy użyciu Open API.

Tyle tytułem wstępu. Jeżeli ktoś z Was chciałby tak jak ja zacząć przygodę z dodatkami do ReSharpera na pewno zacząłby od googla, a ten skierowałby go prosto na strony JetBrains dotyczącą tego właśnie zagadnienia. Jak wszyscy dobrze wiemy z autopsji, dokumentacji nikt nie lubi pisać. Widać, że chłopaki z JetBrains mieli dobry start, bo do wersji 2.5 jest przynajmniej wstęp do pisania dodatków. Do wersji 3.0 są tylko PowerToy’e obrazujące wykorzystanie niektórych funkcji API. Do wersji 4.0 nie ma jeszcze nic (na forum ReSharpera pojawiły się już informacje, że PowerToy’e zostały już zmigrowane do najnowszej wersji i jak tylko przejdą proces weryfikacji to pojawią się do ściągnięcia).

Brak dokumentacji do najnowszej wersji wcale mnie nie zniechęcił. Mamy przecież Reflectora, a w razie niejasności zawsze możemy popytać na forum. Niestety okazuje się też, że od wersji 2.5 sporo się zmieniło. Podczas przerabiania PowerToy z wersji 3.0 na wersję 4.0 okazało, że niektóre typy zniknęły, a pewne interfejsy zostały uproszczone. To oczywiście dobrze, bo widać, że w źródłach robione są pewne porządki. Ostatnio na swoim blogu Ilya Ryzhenkov pisał o kolejnych krokach w rozwoju narzędzia. Możemy się zatem spodziewać kolejnych zmian.

Dostępnych pluginów nie jest zbyt dużo. Mamy dziewięć oficjalnych na stronie JetBrains, a ponadto możemy znaleźć jeszcze kilka na stronach CodePlex, CodeProject itd. Jednak nie jest to duża liczba. W Sieci nie znajdziemy również wielu tekstów dotyczących tworzenia dodatków. Najwyższy więc czas zmienić ten stan rzeczy!

Spis treści:

1. Wprowadzenie (ten tekst)
2. Przygotowanie środowiska
3. ... (dalej zobaczymy, dopiero poznaję zagadnienie)

TfsSpotlight odsłona piąta (v0.5)

Kilka dni temu wydałem kolejną wersję mojego małego projektu. W piątej iteracji dodałem możliwość tworzenia nowych jednostek roboczych (ang. work item) oraz zmieniłem sposób zarzadzania poszczególnymi serwerami.

Dla tych, którzy nie wiedzą czym jest TfsSpotlight:

• Jest to aplikacja wykorzystująca API Team Foundation Server.
• Pozwala na przeglądanie oraz modyfikację jednostek pracy.
• Poszczgólne zapytania oraz konkretne jednostki pracy można przeglądać jednocześnie dzięki zakładkom.
• Jest niezależne od Visual Studio i dzięki temu można niezależnie np. pobierać wersję z serwera i przeglądać jednostki pracy.
• Ułatwia szybkie znalezienie jednostki pracy dzięki funkcji GoTo.
• Jest ergonimiczny, co pozwala skupić się na wykonywanej pracy a nie na niedociągnięciach aplikacji.

Przede mną kolejna iteracja a w niej:

• Historia jednostek pracy, których dotyczyły nasze operacje (tworzenie, modyfikacja).
• Udogodnienia w dostępie do projektów.

Aplikacja jest dostępna jak zwykle w postaci archiwum zip, instalatora windows oraz pakietu autoaktualizacji (dla tych co już mają ją zainstalowaną).

Udanej pracy!

Nocny ReSharper 4.0

Odkąd zacząłem używać Resharpera moje dotychczasowe życie programisty zmieniło się nie do poznania. Nie jest to bynajmniej długa historia, ale faktem jest, że odbiła się piętnem na mojej codziennej pracy.

W lutym wystartował proces nocnych buildów nowej wersji Resharpera. Buildy te są publicznie dostępne. Każdy kolejny build zawiera nową 30-dniową licencję. Dzięki temu mogę korzystać z tego wspaniałego narzędzia i cieszyć się zaoszczędzonym czasem (przynajmniej do czasu premiery tej wersji). Później nie pozostanie nic innego jak zakupić licencję dla siebie. Co ciekawe warunki licencji personal pozwalają na używanie Resharpera zarówno w domu jak i w pracy. Warunkiem jest to, żeby używała go osoba, która zakupiła licencję. Cieszy mnie to bardzo, bo dzięki temu R# będzie mógł być zawsze blisko mnie ;). A skoro w planach mam taki zakup to nikogo nie zdziwi fakt, że zależy mi na tym, aby powstał produkt wysokiej jakości. Zarejestrowałem się więc w ich systemie śledzenia błędów i tam właśnie lądują wszystkie moje uwagi i znalezione błędy. Was również zachęcam do czynnego udziału.

Dwa miesiące pacy z wersją 4.0 i ponad miesiąc z wersją 3.0 i jestem zachwycony, żeby nie powiedzieć uzależniony. Tym co jeszcze nigdy nie spróbowali, a pracują w środowisku VSC#, polecam gorąco. Tym co używają wersji wcześniejszej polecam wypróbowanie któregoś z nocnych buildów wersji 4.0. A ja zadaję sobie pytanie: czemu tak późno zacząłem tego używać?!

Thank you JetBrains!

Biblioteka dostępu do TFS i testy jednostkowe

W poście Tfs Spotlight – buduję własny CAB wprowadzającym do mojego projektu TfsSpotlight wspomniałem, że jednym z moich celów jest pisanie testów jednostkowych. Chcę w ten sposób zobaczyć jakie problemy pojawią się podczas pisania testów jednostkowych dla większego i bardziej skomplikowanego projektu niż te, które do tej pory robiłem.

Proces pisania testów jednostkowych nie jest łatwy i co jakiś czas napotykam pewne problemy. Ostatni problem pojawił mi się w momencie, gdy chciałem napisać test dla klasy prezentera, który obsługuje widok konkretnego workitema. Źródłem danych dla tego widoku jest obiekt klasy pochodzącej z biblioteki dostępu do TFS – klasa WorkItem. Jak się szybko okazało napisanie testu jest niemożliwe, jeżeli bierzemy przypadek całkowitego odizolowania. Wszystko to dlatego, że nie mogę ręcznie utworzyć instancji tej klasy. Do tego potrzebne jest połączenie z serwerem (sic!). Moje zamiary spełzły na niczym. W dodatku klasa ta jest sealed, więc Rhino Mocks robie nie radzą. Nie mam zielonego pojęcia jak sobie z tym poradzić.

Wracając do biblioteki TFS pozwalającej na dostęp do serwera to należy zauważyć, że programiści i projektanci tego API zabezpieczyli się przed nieumiejętnym jego wykorzystaniem, aby zapobiec nadmiernemu obciążeniu serwera. Elementy takie jak Project, Query, WorkItem czy ich kolekcje są zaimplementowane w postaci klas, które swoje dane ładują w sposób leniwy. Tym sposobem wyświetlając w tabeli workitemy, pobierane są tylko właściwości wyświetlane w kolumnach. Pozostałe nie zostaną ściągnięte. Takie zachowanie na pewno ogranicza ilość danych przesyłanych z serwera, ale niestety sposób wykonania tych elementów może pozostawiać wiele do życzenia. Wszystkie te klasy o których mowa są sealed, a serwisy nie zostały opisane żadnymi interfejsami definiującymi kontrakty. Wygląda na to, że w tym przypadku nie pomyślano o Zasadzie oddzielenia zagadnień (ang. Separation of Concerns). Podobnie jest z kontrolkami dostarczanymi w bibliotece TFS. Okazuje się, że podpinając im źródło danych one i tak pytają o coś serwer (sic!)

Budując system luźno powiązany praca z takimi komponentami jest bardzo uciążliwa, a w tym przypadku skutecznie uniemożliwia mi pisanie testów. Chociaż trzeba zaznaczyć, że jest światełko w tunelu. Od jakiegoś czasu co raz częściej słyszy się o co raz to nowszych projektach ze stajni MS, które wspominają o testach jednostkowych. Ba, wczoraj Scott Guthrie ogłosił, że Silverlight 2 jest testowany przy pomocy testów jednostkowych (jest ich ponad 2000) i co więcej dostarczają również narzędzi do testowania własnych projektów Silverlight-owych.  Bardzo mnie ten trend cieszy, gdyż może następna wersja biblioteki dostępu do TFS będzie ten trend uwzględniała.

Globalizacja aplikacji i wątki

Natknąłem się na pewne zachowanie .Net Frameworka, które było zupełnie odmienne od tego, którego się spodziewałem. Problem dotyczy globalizacji i wątków. Okazuje się, że mając aplikację, która jest zlokalizowana na wiele języków musimy zwrócić szczególną uwagę za każdym razem gdy korzystamy z wątków.

Ustawienia dotyczące kultury są właściwościami wątku. W systemie Windows przy starcie wątku ustawienia kultury pobierane są z ustawień systemowych. Zatem jeżeli uruchamiamy aplikację, jej watek otrzymuje ustawienia użytkownika. Działanie to jest jak najbardziej oczekiwane. Okazuje się jednak, że tworzone w aplikacji kolejne watki otrzymują ustawienia kulturowe w taki sam sposób jak wątek pierwszy. Może nie było by w tym nic złego, ale osobiście oczekiwałem zachowania odwrotnego – czyli że nowy wątek otrzyma takie same ustawienia jak wątek główny. Natomiast gdy w międzyczasie zmienimy ustawienia kulturowe pierwszego wątku to pojawiają się dodatkowe problemy.

Wyobraźmy sobie aplikację, która przed uruchomieniem wyświetla okno, w którym możemy wybrać język w jakim chcemy, żeby się uruchomiła. Wybierając język inny niż ten, który znajduje się w ustawieniach systemu, będziemy działać swobodnie dopóki nie aplikacja nie zacznie korzystać z wątków.

Ja, będąc niedoświadczonym programistą, założyłem, że skoro aplikacja ma określone ustawienia kulturowe w pierwszym wątku, to tworząc nowe wątki ustawienia te zostaną zachowane (skopiowane z wątku, który tworzy nowe watki). Okazuje się jednak, że CLR nie zawiera żadnego mechanizmu kontrolowania ustawień kulturowych wątków tworzonych w danym procesie. Dlatego każdy tworzony wątek będzie miał ustawienia te pobrane z systemu Windows.

Dobrze, skoro już wiemy o tych niuansach, to trzeba się do tego przystosować. Jeżeli ręcznie tworzymy wątki to nie ma z tym żadnego problemu. Klasa Thread ma odpowiednie właściwości, dzięki którym możemy ustawienia kulturowe ustawić według własnego uznania. Ja jednak korzystam zwykle z puli wątków (klasa ThreadPool). Jak się szybko okazało klasa ta nie ma żadnego bezpośredniego wsparcia dla uruchamiania wątków z innymi ustawieniami kulturowymi. A szkoda. Skoro reguły są jasne, to powinniśmy chociaż dostać jakieś przeciążenie metody QueueUserWorkItem pozwalające określić ustawienia kulturowe uruchamianego wątku. A tak trzeba się tym ręcznie bawić i określać ustawienia kulturowe już w metodzie, uruchomionej w osobnym wątku, co moim zdaniem tylko wprowadza niepotrzebne zamieszanie w kodzie. Uważam, że można było tego uniknąć udostępniając odpowiednie API.

Podsumowując okazuje się, że pracując z aplikacją, która ma być lokalizowana na inne języki musimy szczególną uwagę zwrócić na obsługę wątków i odpowiednio ustawiać im właściwości kulturowe. Niemniej jednak zachowanie to jest dla mnie zgoła nie intuicyjne. Bo przecież zwykle chcemy, aby cała aplikacja działała z tymi samymi ustawieniami kulturowymi, a przypadki odwrotne są raczej sporadyczne. A może jest jakieś dobre uzasadnienie tego stanu rzeczy?

Tfs Spotlight v0.3

• Dodano możliwość otwierania poszczególnych workitemów w osobnych zakładkach. Wystarczy kliknąć dwa razy na dany workiem i otworzy się on w nowej zakładce.
• Dodano możliwość otwierania workitemów po bezpośrednim podaniu id oraz wyborze serwera. Operację tę można wykonać też bez użycia myszy. Zdefiniowany został skrót klawiszowy Ctrl + G, który przenosi fokus do pola, gdzie należy wpisać id workitema. Następnie wciskając klawisz Enter możemy rozwinąć listę dostępnych serwerów, albo jeżeli mamy tylko jeden serwer, od razu otworzyć zakładkę z workitemem o podanym id.
• Dodano możliwość przechodzenia między zakładkami za pomocą kółka myszy.

Dla tych co już używają tego programu umieściłem też pakiet do auto aktualizacji. Przy uruchomieniu aplikacji powinien pojawić się monit proponujący aktualizację. To będzie próba generalna tego mechanizmu :)

Miłej pracy!

Tfs Spotlight – buduję własny CAB

Od kilku miesięcy nic tu nie pisałem (oczywiście poza poprzednim nieplanowanym wpisem). Jak łatwo się domyślić czas mi na to nie pozwalał. Z jednej strony natłok zadań w pracy (stabilizacja finalnej wersji – Comarch ALTUM ujrzał niedawno światło dzienne na tegorocznym CeBicie) a z drugiej strony projekt, który chciałbym opisać w tym tekście.

Pierwsze odcinki z serii Build your own CAB pojawiły się już dość dawno, a ponieważ Jeremy jest moim ulubionym bloggerem, to śledzę je od początku z zainteresowaniem i nie mogę się doczekać następnych (ciekaw jestem ilu z Was także czyta regularnie jego teksty). Osobiście jako zawodowy programista mam jeszcze niewielką praktykę w budowaniu złożonych aplikacji, ale czytając ciągle różne teksty, pojawiające się na blogach, moja głowa wypełnia się wiadomościami teoretycznymi, a po przeczytaniu wszystkich dostępnych dotąd artykułów z Serii zapragnąłem tę wiedzę wykorzystać w praktyce.

Pracę jako programista zacząłem właśnie od aplikacji budowanej w oparciu o Composite Application Block, pracuję z nią już ponad rok, a Seria Jeremy’ego pozwoliła mi z dystansu spojrzeć na rozwiązania zastosowane w CAB, lepiej je zrozumieć i wykorzystać. Ponadto chęć poszerzania swoich doświadczeń i umiejętności pchnęła mnie dalej. W Sieci można znaleźć pomysł, by Serię opatrzyć przykładami. Ten pomysł zachęcił mnie by wykorzystać zdobytą wiedzę w praktyce i wykonać jakiś projekt open source. Tak na marginesie trzeba zauważyć, że i tak najlepszym przykładem jest projekt Story Teler Jeremy’ego, z którego to pochodzi większość przykładów, które możemy zobaczyć w Serii.

Pomysł ten pojawił się w momencie, gdy szukałem trochę wolnego czasu by zająć się projektem dotyczącym Team Foundation Server Workitem Tracking, czyli po prostu zarządzaniem workitemami. Na co dzień pracuję w środowisku TFS i do tego celu używam programu Fissum. Program ten jest naprawdę sprytny i pozwala mi lepiej wykorzystać mój czas. Gdy pobieram wersję z repozytorium, bądź też kompiluję projekt, Team Explorer nie nadaje się do użytku, tak jak i całe Visual Studio. Są po prostu zablokowane. Inną sprawą jest to, że TE w ogóle jest toporny i wolny - czytałem, że w VS2008 ma być o niebo lepiej. Pożyjemy, zobaczymy. Program zewnętrzny, taki jak Fissum, powala mi w tym czasie zająć się moimi workitemami. W szczególności najczęściej korzystam z niego w fazie stabilizacji, w której zwykle mam do czynienia z błędami, które muszę poprawić. Dzięki niemu w czasie, gdy Visual Studio jest zajęte, mogę na boku analizować przychodzące błędy jak i weryfikować te już istniejące. To jest mój sposób na optymalizację czasu, a czas przecież trzeba szanować (szczególnie, gdy harmonogram ciśnie).

Można zapytać: skoro tak dobrze Ci się pracuje z Fissum, to czemu chcesz pisać swoje oprogramowanie? Przede wszystkim chodzi o naukę. Generalnie aplikacja ma być prosta, jednak z drugiej strony będzie na tyle skomplikowana, że większość tematów poruszanych w Serii znajdzie w niej zastosowanie - chociażby implementacja UI, komend, stanu menu, zakładek itd. Drugim celem było zapoznanie się z narzędziami, które od dawna czekają na półce - mam tu na myśli jakiś kontener IoC (w moim wypadku StructureMap) oraz bibliotekę do logowania (Logging Application Block już widziałem w akcji u Arka, więc wypadałoby z niego skorzystać). Trzecim powodem jest to, że projekt Fissum mimo że jest otwarty (open source), to jednak jest zamknięty. Program ten zawiera kilka rzeczy, które mi przeszkadzają. O jednej już pisałem. Ponadto mam kilka pomysłów jak można by było go usprawnić (generalnie chodzi o użyteczność a nie o funkcjonalność). Proponowałem Miiitchowi swoją pomoc jednak powiedział mi, że jest to jego prywatny projekt, na którym realizuje swoje pomysły dotyczące TFS. Trzeba to uszanować. Na początku modyfikowałem Fissum do swoich potrzeb, ale jest to uciążliwe do utrzymania, gdy Miiitch wydaje nowe wersje.

W niniejszym tekście chciałbym opisać kilka problemów, które napotkałem budując TfsSpotlight oraz znalezionych dzięki Serii rozwiązań. Jakoś tak wyszło, że zacząłem trochę od końca. W swojej Serii Jeremy nie poruszył jeszcze tematu Application Shell, a w momencie gdy pisałem pierwszą wersję aplikacji nie było też tekstu o Command Executor, a aby zbudować podstawę, trzeba było zacząć właśnie od tych elementów. Dlatego właśnie rozwiązania zawarte w TfsSpotlight dotyczące tych zagadnień są tylko i wyłącznie mojego pomysłu.

Oddzielenie logiki aplikacji od formatek

Po prezentacji Wojtka o MVC chyba każdy się ze mną zgodzi, że budując chociażby kalkulator należy oddzielić logikę dziedziny od sposobu prezentacji. Pierwszą i dla mnie najważniejszą zaletą takiego podejścia jest możliwość łatwego przetestowania logiki bez konieczności angażowania w ten proces komponentów graficznych. Nie napisałem tego wcześniej, ale w tym projekcie jednym z większych dla mnie wyzwań jest zadanie pisania testów jednostkowych dla jak największych części kodu. Co z tego wyjdzie – zobaczymy.

Od dłuższego czasu przy budowaniu formatek korzystam z pewnego wariantu wzorca Model-View-Presenter. Mówię tu wariantu, gdyż, tak jak już wspominał Wojtek na swojej prezentacji, nie ma jednej najlepszej implementacji wzorca MVP. W moim wykonaniu widok odpowiada wzorcowi PasiveView (Fowler, Jeremy), gdyż jest to postać najbardziej przyjazna testowaniu, bo zawiera minimalną ilość logiki. Prezenter jest główną jednostką dowodzącą, która zawiera wszelką logikę prezentacji i obsługi danego widoku - SupervisingController (Fowler, Jeremy). Z modelem natomiast bywa różnie. W prostych przypadkach są to bezpośrednio encje reprezentujące dane, na których dany widok pracuje. W przypadkach bardziej skomplikowanych preferuję oddzielną klasę modelu, która w szczególności zawiera logikę obsługi danych tj. wczytywanie, zapisywanie. Ma to szczególne znaczenie, gdy widok ma wiele źródeł danych (np. listy wyboru, które również trzeba zasilić danymi z bazy). W takich przypadkach model zajmuje się przygotowaniem wszystkich potrzebnych zestawów danych i odciąża tym prezentera. W niniejszym projekcie taka skomplikowana sytuacja jeszcze nie zaszła, gdyż biblioteki TFS dostarczają nam gotowych kontrolek do reprezentacji całych elementów, toteż zostałem zwolniony z konieczności implementowania ich własnoręcznie.

Wykorzystując MVP preferuję podejście bazujące na bezpośrednim odwoływaniu się widoku do prezentera. W porównaniu z podejściem opartym na zdarzeniach jest to podejście znacznie prostsze. Przede wszystkim dlatego, że prostsza jest nawigacja po kodzie. Mając bezpośrednie odwołania do metod możemy wykorzystać narzędzia nawigacyjne, jakie daje nam Visual Studio, i przemieszczać się z widoku do prezentera dwoma kliknięciami myszy. Sprawa się trochę komplikuje, jeżeli prezenter jest opisany interfejsem. Wtedy niestety VS sobie nie radzi i pokazuje nam implementację interfejsu, a nie kod konkretnego prezentera, czyli nie do końca tego, czego byśmy chcieli. Problemu tego nie mają użytkownicy ReSharepera, którego genialna funkcja Go to inheritor pozwala natychmiast przemieścić się do klasy implementującej dany interfejs. Poza tym implementacja zdarzeń wymaga od nas o wiele większego nakładu pracy. Należy przecież w widoku zaimplementować zdarzenia dla każdej możliwej do wykonania operacji. Następnie w prezenterze trzeba do tych wszystkich zdarzeń podpiąć odpowiednie metody. Jak dla mnie za dużo roboty.

Zarządzanie komendami

Pytanie jest proste: jak zarządzać komendami, które użytkownik może wykonywać? Wymagania zwykle są następujące:

1. Komenda powinna być dostępna w wielu miejscach aplikacji: menu główne, menu kontekstowe, ikona na pasku narzędzi, skrót klawiszowy, wywołanie z kodu programu nawet w innym module.
2. Zarządzanie stanem komendy – czy jest aktywna czy nie.
3. Sposób uruchomienia komendy – synchroniczne czy asynchroniczne – w samej implementacji komendy chcielibyśmy abstrahować od sposobu jej uruchomienia.

Jak nie trudno się domyśleć bez spójnego mechanizmu definiowania i obsługi komend szybko zabrniemy w ślepy zaułek i rozwijanie aplikacji stanie się nieprzyjemne. Z resztą bez odpowiedniego mechanizmu trudno będzie w prosty sposób zarządzać choćby stanem poszczególnych komend. Z pomocą przychodzi nam bardzo prosty wzorzec – Komenda (Jeremy). Wzorzec ten wprowadza interfejs komendy – ICommand – dzięki któremu możemy wykonanie każdej komendy zunifikować do postaci wykonania jednej metody ICommand.Execute(). Osobiście nigdy nie wykorzystywałem jeszcze tego podejścia, znałem je jedynie z definicji. Pierwsze pytanie jakie mi się nasunęło to jak dana komenda ma poznać swój kontekst (czyli dane na których ma pracować)? Przecież metoda Execute nie przyjmuje żadnego parametru! Tutaj zrozumiałem, że aby dobrze zaimplementować ten wzorzec trzeba do tego odpowiednio nasz system przygotować.

Na przykład rozważmy interfejs programu, który opiera się na zakładkach. Z reguły będziemy mieli jeden pasek z przyciskami i jedno menu główne, gdzie umieścimy komendy dotyczące aktywnej zakładki. Aby móc dostarczyć tym komendom kontekstu należy wprowadzić jakiś sposób pobierania aktywnej zakładki, aby komenda mogła oddelegować do niej akcję. Podobnie należy pomyśleć o innych elementach powłoki, do których będziemy chcieli mieć dostęp. Wydzielenie odpowiednich serwisów pozwala szybko odpowiedzieć na pytanie „jak dana komenda ma uzyskać interesujące ją dane”.

Kontynuując zadanie, potrzebny jest nam teraz spójny sposób obsługi komend. Po pierwsze potrzebujemy jednolitego sposobu przypisywania komend do kontrolek, a po drugie jakiegoś mechanizmu pozwalającego te komendy uruchamiać. Zajmijmy się teraz pierwszym zadaniem, a drugie omówimy sobie trochę później.

Od jakiegoś już czasu obserwuję w eterze coraz częściej pojawiające się odwołania do tekstu Martina Fowlera o fluent interfaces. Co więcej, zauważyć można pojawiające się implementacje wykorzystujące ten sposób budowania interfejsów klas. Prawdę mówiąc, gdy po raz pierwszy przeczytałem ten artykuł, idea bardzo mi się spodobała, ale nie widziałem jeszcze konkretnego jej zastosowania. Dopiero później, używając Rhino Mocks zauważyłem, że przecież używam właśnie fluent interface! I rzeczywiście, do zadań konfiguracyjnych podejście to jest niezastąpione, a wynikowy kod jest niesamowicie czytelny. Idąc za przykładem Jeremy’ego konfigurację komend zaimplementowałem wykorzystując tę technikę. Z wyniku jestem bardzo zadowolony, gdyż powstał naprawdę bardzo elastyczny, a zarazem spójny mechanizm przypinania komend do interfejsu użytkownika. Sposób implementacji możecie zobaczyć w kodzie (plik ConfigureMenuExpression.cs). Poniżej przedstawię tylko wynik użycia tej klasy konfiguracyjnej.

Przykład [C#] 1. Przykład wykorzystania klasy konfiguracyjnej wykorzystującej fluent interface.

ConfigureMenuExpression
    .Execute(CommandsNames.ExitApplication)
    .Synchronous()
    .For(this.miExit)
    .For(this.tsbExit)
    .WithShortcut(Keys.F10)
    .Enable();

ConfigureMenuExpression
    .Execute(CommandsNames.SaveAllWorkItems)
    .For(this.tsbSaveAll)
    .WithShortcut(Keys.Control | Keys.Shift | Keys.S)
    .Disable();

Dzięki zastosowaniu takiego mechanizmu udało mi się zebrać całą logikę dotyczącą konfiguracji komend w jednym miejscu. Jak łatwo zauważyć spełniłem większość wymagań postawionych wcześniej. Po pierwsze daną komendę możemy przypisać do wielu elementów, możemy nadać skrót klawiszowy, możemy oznaczyć jako operację synchroniczną (domyślnie komendy uruchamiane są w trybie asynchronicznym) oraz możemy nadać komendzie początkowy stan. Wszystko w jednym miejscu, wszystko czytelne do granic możliwości. Kontrastując to z koniecznością odpalenia formatki w trybie projektowania, nawigowaniu po elementach menu i sprawdzaniu w panelu właściwości czy podpięta jest odpowiednia metoda i czy został dobrze zdefiniowany skrót klawiszowy widać jak wiele zalet ma przedstawione tu podejście.

Powłoka – application shell

Jak to wszystko ze sobą powiązać?

Każdy, kto choć trochę liznął wzorców projektowych GoF, do tego problemu podszedłby z Singletonem pod pachą. Implementując każdy z serwisów powłoki w postaci singletonu umożliwiamy innym elementom systemu łatwy dostęp do instancji tych serwisów. Niestety singleton ma jedną poważną wadę – bardzo, ale to bardzo mocno wiąże ze sobą klasy. Klasa, która odwołuje się do elementów statycznych innej klasy jest z nią bardzo mocno związana. Dlaczego nie chcemy takiego mocnego powiązania? Przecież miliony programistów na całym świecie używają singletonów z powodzeniem. Otóż tak mocne powiązania nie pozwalają efektywnie testować klas w izolacji, a przecież o to właśnie chodzi w pisaniu testów jednostkowych – żeby poszczególne klasy testować w izolacji. Zatem z mojego punktu widzenia i z punktu widzenia testów jednostkowych silngleton wypada blado. Na marginesie należy dodać, że istnieją narzędzia pozwalające testować takie sytuacje. Narzędziem takim jest TypeMock, które w środowisku praktyków TDD jest dość kontrowersyjne.

Z pomocą przychodzi nam zasada odwracania zależności (Dependency Inversion Principle) i narzędzia pozwalające tę zasadę wprowadzać w życie, czyli kontenery IoC (Inversion of Control). Osobiście w żadnym z moich prywatnych projektów nie korzystałem jeszcze z tego typu narzędzi. Naturalnym moim wyborem oczywiście jest StructureMap Jeremy’ego. W momencie, gdy piszę ten tekst, na horyzoncie jest już Unity ze stajni Microsoftu. David Hayden zrobił screencast wprowadzający w jego użycie.

1. Moduły wysokiego poziomu nie powinny być zależne od modułów niższego poziomu. I jedne i drugie powinny być zależne od abstrakcji.
2. Abstrakcje nie powinny być zależne od szczegółów. To szczegóły powinny być zależne od abstrakcji.

1. Zależność od typu (ang. dependency on a type) oznacza, że egzemplarz usługi musi implementować pewien dobrze określony typ, który może być zdefiniowany za pomocą interfejsu, klasy abstrakcyjnej bądź konkretnej klasy.
2. Zakodowana zależność (ang. hard-wired dependency) oznacza, że egzemplarz usługi musi być konkretnego typu. Zwykle odwołanie do konstruktora usługi lub elementu statycznego prowadzi do powstania zakodowanej zależności.

Aby lepiej zobaczyć o czym mówi ta zasada, przeanalizujmy przykład dwóch klas, które zaprojektowano bez jej uwzględnienia.

Przykład [C#] 2. Przykład dwóch klas zaprojektowanych bez uwzględnienia zasady odwracania zależności.

public class RefreshQueryCommand : ICommand
{
    public void Execute()
    {
        ITabPresenter presenter = TabsService.Instance.GetActiveTab();
        if (presenter != null)
        {
            presenter.HandleRefresh();
        }
    }
}

W przykładzie 2 mamy dwie klasy. Klasa RefreshQueryCommand reprezentuje komendę odświeżającą zakładkę. Druga klasa – TabsService – reprezentuje serwis obsługujący zakładki i została zaimplementowana w postaci singletonu. Klasa RefreshQueryCommand ma zakodowaną zależność do klasy TabsService. Jest to spowodowane odwołaniem się do statycznej właściwości tej klasy. Taka sytuacja skutecznie utrudnia nam przetestowanie komendy w izolacji. Testując ją chcielibyśmy sprawdzić dwa przypadki: jeżeli aktywna zakładka istnieje operacja powinna zostać do niej oddelegowana natomiast jeżeli nie to nic nie powinno zostać wykonane. Niestety bezpośrednie odwołanie do klasy TabsService utrudnia nam odpowiednie przygotowanie kontekstu testu.

Problemy te pomaga nam ominąć zasada odwracania zależności. Dzięki niej pozbędziemy się niechcianego odwołania do statycznej właściwości klasy TabsService. Zasada mówi, że tak moduły wysokiego poziomu jak i moduły niskiego poziomu powinny zależeć od abstrakcji. Spróbujmy zatem wprowadzić abstrakcję do przykładu 2. W module wyższego poziomu – klasie RefreshQueryCommand – chcemy abstrahować od klasy TabsService. Opiszmy zatem klasę TabsService interfejsem. Jego definicje przedstawiono w przykładzie 3.

Przykład [C#] 4. Ulepszona realizacja klas RefreshQueryCommand.

public class RefreshQueryCommand : ICommand
{
    private ITabsService TabsService { get; set; }

    public RefreshQueryCommand(ITabsService tabsService)
    {
        this.TabsService = tabsService;
    }

    public void Execute()
    {
        ITabPresenter presenter = this.TabsService.GetActiveTab();
        if (presenter != null)
        {
            presenter.HandleRefresh();
        }
    }
}

Na czym polega odwrócenie zależności przedstawione w przykładzie 4? Zauważmy, że w obecnej sytuacji klasa RefreshQueryCommand nie zależy już od klasy TabsService, ale od interfejsu ITabsService. Odwrócenie zależności polega na tym, że teraz klasa TabsService również zależy od interfejsu ITabsService. Zatem zarówno klasy wyższego jak i niższego poziomu zależą od abstrakcji a nie od konkretnych realizacji.

Wśród narzędzi do zarządzania zależnościami możemy przebierać. Począwszy od wspomnianego StructureMap, czy Unity, po Spring.Net oraz Castle Windsor (w szczegóły wprowadzi Was Michał Harasimowicz na XXII spotkaniu wg.net – mam nadzieję, że pojawi się jakieś nagranie z tej sesji :). Ja swój projekt oparłem o pierwszy z nich. Zasada działania jest banalnie prosta. Najpierw musimy wrzucić do kontenera zabawki, aby potem pojawiły się automatycznie, gdy będziemy ich potrzebować. Większość z kontenerów obsługuje dwa typy wstrzykiwania implementacji: poprzez konstruktor oraz poprzez settery. Ja osobiście wolę pierwszy ze sposobów, ale to kwestia wyboru.

Zwykle, budując system luźno powiązany, opieramy się na interfejsach definiujących kontrakty. Tak też zrobiłem w moim projekcie. Każdy ze wspomnianych wcześniej serwisów powłoki opisany został interfejsem. Po zarejestrowaniu konkretnych implementacji tych interfejsów w kontenerze mogę bez ograniczeń z nich korzystać. Teraz, jeżeli dana klasa potrzebuje instancji danego serwisu, to do jej konstruktora dodaję parametr o typie będącym interfejsem tego serwisu. Zmienia się tylko sposób tworzenia instancji klas. Teraz zamiast używać słowa kluczowego new skorzystać należy z kontenera, aby ten przygotował na instancję żądanej klasy. Zadaniem kontenera jest znalezienie konstruktora i wypełnienie go wszystkimi wymaganymi parametrami. Parametry te są rozpoznawane na podstawie typów. W taki oto magiczny sposób zabawki automatycznie pojawiają się w piaskownicy.

Dzięki wykorzystaniu kontenera możemy budować klasy, które wszystkie swoje zależności otrzymują z zewnątrz. Oznacza to, że klasy te, same nie tworzą innych obiektów potrzebnych im do współpracy. Patrząc z punktu widzenia testów jednostek potencjalny zysk jest wielki. Teraz, aby daną klasę przetestować w izolacji, wystarczy, że utworzymy jej instancję z zależnościami będącymi obiektami zastępczymi (ang. mock objects). Dzięki temu testując możemy się skupić na kodzie tylko i wyłącznie testowanej klasy, a nie usług, od których testowana klasa zależy.

Pozbywając się singeltonów tracimy także kontrolę nad tym ile instancji danej klasy powstanie. A co jeżeli rzeczywiście chcieliśmy, aby dana klasa miała tylko jedną instancję? Otóż nic prostszego. Kontener daje nam możliwość określenia w jaki sposób instancja danej klasy ma być kontrolowana. Sposób wykonania tego z użyciem StructureMap opisał Jeremy na stronie projektu.

Uruchamianie komend - command runner

Nie wiem jak pozostałe kontenery, ale StructureMap ma bardzo fajną opcję rejestrowania instancji konkretnych klas pod pewną ustaloną nazwą. Później, chcąc otrzymać tę nazwaną instancję możemy zapytać kontener podając mu właśnie tę nazwę. Opcja ta jest o tyle sprytna, że pozwala w banalny sposób spełnić pozostałe wymagania dotyczące obsługi komend, o której pisałem wcześniej.

Jak można było zauważyć wcześniej przy konfiguracji komend, nigdzie nie podaliśmy ani klas, ani metod obsługujących konkretne komendy. Jedyne co widzieliśmy to stała w postaci CommandsNames.ExitApplicationCommand. Aby zbudować system elastyczny, który będzie spełniał wszystkie wymagania, nie mogliśmy podczas konfiguracji komend podać ich konkretnych implementacji chociażby dlatego, że implementacja danej komendy wcale nie musi znajdować się w klasie dostępnej podczas kompilacji. Dlatego właśnie do identyfikacji komend używamy stałych napisowych. Stałych tych używamy przy rejestracji implementacji komend w kontenerze, a dzięki temu znając nazwę komendy możemy później zapytać kontener o jej instancję.

Przykład [C#] 5. Realizacja klasy uruchamiającej komendy.

public class CommandRunner : ICommandRunner
{
    public void Run(string commandName)
    {
        Run(commandName, true);
    }
    public void Run(string commandName, bool runInAsync)
    {
        var command = ObjectFactory.GetNamedInstance<ICommand>(commandName);
        if (runInAsync)
        {
            ThreadPool.QueueUserWorkItem(delegate { command.Execute(); }, null);
        }
        else
        {
            command.Execute();
        }
    }
}

Dzięki opisaniu komend wspólnym interesem implementacja klasy CommandRunner staje się banalnie prosta. Ponadto klasa ta też została opisana intefjesem i zarejestrowana w kontenerze dzięki czemu nawet klasy z innych assembly mogą się do niej odwoływać i wykonywać komendy.

Ktoś z Was może zauważyć, że rzeczywiście staramy się tworzyć system luźno powiązany a jednocześnie korzystamy z kontenera, który dostarcza implementacji wymaganych typów za pomocą statycznej klasy ObjectFactory (sic!). Prawda jest taka, że niestety kontener nie może dostarczyć instancji samego siebie więc, akurat w tym przypadku nic nie możemy zrobić. Dlatego trzeba ograniczać miejsca, gdzie będziemy się bezpośrednio odwoływać do niego. Dobrą praktyką, pozwalającą łatwo testować takie odwołania, jest umieszczenie tego odwołania w metodzie wirtualnej, którą na czas testów będziemy mogli nadpisać i zwrócić z niej to, czego będziemy potrzebowali w kontekście testu.

Podsumowanie

Zachęcam wszystkich, którzy jeszcze nie czytali Serii, by w wolnej chwili to zrobili. Zachęcam w szczególności tych, którzy podobnie jak ja, pracują z CAB na co dzień. Nie chodzi oczywiście o to by każdy z nas budował własny CAB, ale by poznać techniki i koncepcje pozwalające pisać lepszy kod i lepiej projektować systemy.

Projekt, którego część tutaj opisałem, na pewno nie jest idealny, ale jego budowanie przynosi mi wiele satysfakcji. Na pewno w miarę wolnego czasu będę go rozwijał. Jeżeli komuś z Was się przyda to tym lepiej. Wszystkie uwagi są oczywiście mile widziane, tak do samej architektury, jak i funkcji programu.

Automatyczne podłączanie debuggera do procesu - Debugger.Launch();

Od jakiegoś czasu mieliśmy w projekcie jeden dość uciążliwy problem: MasterSolution z blisko trzydziestoma projektami. Jak nie trudno się domyślić było to powodem kilku problemów: długi czas kompilacji, problemy z wydajnością ReSharpera itd. Na szczęście od dziś mogę pracować już tylko z podzbiorem projektów, które mnie interesują, a to wszystko dzięki odpowiedniemu podziałowi MasterSolution.

Rozbicie MasterSolution zmienia niestety sposób w jaki pracowałem do tej pory. Z modelu "Edytuj i F5 (debuguj)" muszę przejść na trochę bardziej skomplikowany "Edytuj, zbuduj, uruchom i podłącz debuggera". Nowy model, choć bardziej skomplikowany, nie będzie bardziej czasochłonny z wyjątkiem jednej monotonnej czynności. Za każdym razem, gdy aplikacja się załaduje, trzeba będzie podłączyć debuggera (Debug->Attach debugger). Jest to o tyle monotonne, że trzeba się trochę naklikać. Pierwsza myśl jaka mi przyszła do głowy to: czy nie da się tego zrobić automatycznie?

Odpowiedź jest częściowo twierdząca, a dokładnie jest nim wywołanie jednej metody klasy System.Diagnostics.Debugger:

Debugger.Launch();

To jedno wywołanie uruchamia debuggera i podłącza go do procesu, z którego pochodzi powyższe wywołanie. Rozwiącanie jest częściowe, ponieważ i tak zmusza nas do kilku kliknięć. Po wywołaniu powyższej linii zobaczymy takie oto znajome okienko wyboru debuggera (po lewej).

Gdy po raz pierwszy mi się to okienko pokazało pomyślałem sobie, że mi się aplikacja wywaliła, ale pokrótce okazało się, że okno jest efektem pożądanym i pozwala wybrać debuggera, którego chcemy użyć. Po tym jak dokonamy wyboru, wybrana przez nas instancja Visual Studio przejdzie w tryb debug, tak jakbyśmy mieli ustawiony breakpoint. I voila! Podpięliśmy się do interesującego nas procesu.

Bardzo mi się to rozwiązanie podoba, gdyż zaoszczędzi mi monotonnego klikania. Wywołanie debuggera można umieścić zaraz przy starcie aplikacji, lub też wstawiać w pożądanym miejscu, tylko na czas debugowania.

Jest jeszcze jedna metoda klasy Debugger, o której chciałbym wspomnieć.

Wywołanie to jest tożsame w ustawieniem breakpointa bezpośrednio w Visual Studio. Zatem czy programowe zatrzymywanie programu może nam się przydać?

Otóż ciekawym zastosowaniem może być sytuacja, gdy w pewnym miejscu programu wiemy, że pewien jego stan jest nieprawidłowy. Jest wiele sposobów na takie miejsca. Możemy na przykład wypisywać komunikat na konsolę. Jeżeli jednak zachowanie to jest niepoprawne, to zwykle będziemy chcieli sprawdzić dlaczego aplikacja znalazła się w danym stanie. Prawdopodobnie wrócimy i ustawimy breakpoint by zbadać stan interesujących nas obiektów. Zatem dlaczego od razu w momencie wystąpienia tego zdarzenia nie zatrzymać programu?

Zatem miłego debugowania!

Zachowywanie stanu okna

Czasami, pisząc własne aplikacje Windows Forms lub używając takich czcielibyśmy, aby aplikacja była choć trochę bardziej spostrzegawcza i np. zapamiętywała atrybuty okna (położenie, rozmiar oraz stan) gdy przestajemy z nich korzystać. Skoro je przestawiliśmy to znaczy, że tam nam lepiej pasują. Dlatego aplikacja zamiast z uporem pokazywać nam okno zawsze w tym samym miejscu mogła by umilić nam życie. Szczególnie, że z programistycznego punktu widzenia nie jest to operacja trudna i pracochłonna.

Ostatnio w mojej codziennej pracy z TFS korzystam z małego narzędzia - Fissum - dającego mi dostęp do zapytań o WorkItemy poza Visual Studio. Dzięki temu, gdy przeprowadzam kompilację, albo pobieram źródła mogę sobie na boku zarzązać WorkItemami. Wszystko by było fajnie, gdyby nie denerwująca przypadłość tej aplikacji. Codziennie, gdy ją odpalam muszę zmienić pozycjęo okna, z którego najczęściej korzystam, ponieważ aplikacja z uporem pokazuje je na środku ekranu oraz w wielkości jaka mnie nie satysfakcjonuje. Postanowiłem to zmienić ;)

Mając na uwadze przyszłe aplikacje, chciałem zbudować rozwiązanie, które będę mógł łatwo wielokrotnie wykorzystywać. Ponadto chciałem zminimalizować ilość kodu jaki będzie potrzebny, aby dany program wzbogacić o funkcję zapamiętywania stanu okien. Dodatkowym atutem rozwiązania byłoby zachowywanie wyżej wymienionych atrybutów w zależności od zalogowanego użytkownika.

Wykorzystując mechanizm Isolated Storage oraz serializację zbudowałem bardzo proste rozwiązanie, które łatwo wykorzystać w dowolnej aplikacji Windows Forms. Użycie jest banalnie proste. Po tym jak utworzymy obiekt okna podajemy go do specjalnej klasy, która na podstawie identyfikatora (również podanego) spróbuje pobrać zapisane dane o stanie. Jeżeli takie znajdzie to aplikuje je do podanego okna. Wywołanie ma następującą postać:

PersistedWindow.Prepare(myForm, "FormIdentifier");

Sprawa jest prosta.

W załączniku znajdują się dwie klasy implementujące powyższe funkcje.

Grupy pasjonackie we Francji

Od jakiegoś czasu z zainteresowaniem i zadowoleniem obserwuję powstawanie zorganizowanej polskiej społeczności skupionej wokół technologii Microsoftu. Nie wszyscy z Was pewnie wiedzą, że od września jestem w Lyonie i to stamtąd oglądam to co dzieje się w Polsce. Na razie trzymam się z boku nie mogąc osobiście uczestniczyć w spotkaniach. Wyjechałem z Wrocławia na krótko przed tym jak narodziła się tam grupa, trochę szkoda. No ale nie wszystko stracone. Jeszcze tam wrócę! :D

Tymczasem chciałem jakoś zadomowić się tutaj. Zachęcony tak prężnymi działaniami rodzimych grup pomyślałem sobie, że na zachodzie może być tylko lepiej i w tak dużym mieście jak Lyon (drugie pod względem wielkości we Francji) na pewno znajdę interesującą grupę. Nie mogę spoytkać się z Wami to chociaż po części odbiję sobie tutaj, a co! A nic! Właśnie nic... Przeszukując pobieżnie Sieć nie znalazłem żadnej grupy z Lyonu...

Zacząłem standardowo - INETA. Wynik wyszukiwania to dziesięć pozycji z których większość to grupy studenckie usytuowane przy politechnikach, niestety żadnej z Lyonu. Druga próba to Culminis. Na stronie jest bardzo użyteczna mapa z naniesionymi grupami. Przybliżając teren Francji znów znajdujemy mniej więcej dziesięć grup rozstrzelonych po kraju. Niestety, ale w okolicach Lyonu panuje chyba jakaś zaraza, bo w promieniu 300km nic nie znajdziemy. Przeszukiwanie za pomocą Googli też nie daje ciekawych wyników...

Z moich pobieżnych poszukiwań wynika, że Francuzi pod względem organizacji grup pasjonackich pozstają daleko w tyle za Polską. Trochę szkoda, bo myślałem, że będę mógł zobaczyć jak to wygląda tu na miejscu i może czegoś ciekawego się nauczyć. Nie pozostaje mi nic innego jak cierpliwie czekać na lipiec 2008 kiedy to zamierzam wrócić do Polski...

Code snippets

Chyba każdy programista korzystający z Visual Studio wie o code snippets i z nich korzysta. Na ich temat mówiło się dużo, najwięcej jeszcze przed premierą Visual Studio 2005. Najczęściej wykorzystywanym skrótem jest pewnie prop, który pozwala nam wstawić właściwość get/set wraz z polem prywatnym, ale i inne pewnie też mają wzięcie ;).

Na potrzeby mojej codziennej pracy chciałem sobie napisać parę takich snippetów, ponieważ dzięki nim nie będę musiał zaprzatać sobie głowy standardami kodowania przyjętymi w projekcie, w którym pracuję. Myślę, że pozwolą mi one pisać kod szybciej.

Do tej pory używałem tylko tych dostarczonych wraz z VS. Teraz przyszła pora na zainteresowanie się tym jak one wyglądają od środka i co można z nimi fajnego zrobić.

W pracy każdą klasę muszę opatrywać atrybutem Author. Pomyślałem więc, że zrobię sobie snippeta, który pozwoli mi dodawać ten atrybut. Ponadto w dokumentacji widziałem, że snippety potrafią dodawać referencje w projekcie a także wstawiać deklaracje using. Bardzo mi się to sposobało, ponieważ atrybut ten leży w przestrzeni nazw, dla której nie ma klauzuli using w szablonie klasu C#. Jakie było moje zdziwienie, gdy się okazało, że snippety oczywiście potrafią wstawiać referencje i usingi, ale tylko w projektach VB :(. Wielka szkoda! (może ktoś z Was wie dlaczego?). Nie mając w zanadrzu tak poręcznej opcji chyba będę zmuszony do zdefiniowania własnego snippetu dla całej klasy.

W Internecie znaleźć można wiele programów pozwalających tworzyć snippety (np. Snipper, który ma fajne kontekstowe podpowiedzi), ale tak naprawdę czy rzeczywiście potrzeba nam okienek, aby napisać kawałek xml'a? Przeglądając dokumentację zobaczyłem, że snippety można również definiować dla plików xml (oprócz C# i VB). Szybka konotacja doprowadziła do tego,  że w mojej głowie zrodził się pomysł, aby zrobić snippet zawierający szablon snippeta!. Jak pomyslałem tak zrobiłem i oto powstał snippet, którego znajdziecie w załączniku do tej notki. Generowany kod ubrałem w komentarze umieszczając w nich pomocne informacje, aby tworzenie snippetów było maksymalnie przyjemne :)

Mam nadzieję, że i Wam się przyda, gdy będziecie chcieli stworzyć własnego snippeta. Teraz, gdy zauważam fragment kodu, który często powtarzam, mogę z kilka minut utworzyć odpowiedniego snippeta. Po prostu otwieram nowy plik xml, wywołuję snippeta dla snippeta, wypełniam pola oraz uzupełniam szblon.

A tu znajdziecie krótki screencast.

SQL: Mały problem i pytanie (jak pobrać ID wstawionych wierszy)

C#: throw; vs throw e;