nblog

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

Wydałem kolejną wersję mojego małego projektu – Tfs Spotlight.

Co nowego w wersji 0.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

Chciałem, aby moja aplikacja składała się z okna głównego (powłoki, ang. shell), które zawierać będzie podstawowe elementy takie jak menu, pasek narzędzi z ikonami, pasek statusu oraz kontener na zakładki. W odróżnieniu od Fissum chciałem, aby TfsSpotlight pracował cały czas w jednym oknie, a za pomocą zakładek pozwalał na otwieranie wielu elementów jednocześnie. Ponadto chciałem dać użytkownikowi bezpośredni dostęp do zapytań zdefiniowanych dla danego projektu, co zaowocowało powstaniem panelu bocznego.


W moim odczuciu zadaniem powłoki jest dostarczenie API pozwalającego na manipulację jej elementami. Dlatego właśnie wydzieliłem z niej kilka serwisów (zarządzanie menu – komendami, zarządzanie zakładkami, zarządzanie paskiem statusu oraz zarządzenie zakładkami). Zdefiniowałem spójne interfejsy opisujące te usługi i dzięki temu dowolny element systemu może mieć dostęp do elementów wspólnych.

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.

Zasada odwracania zależności mówi, że:

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.

Klasa A zależy od klasy B, gdy klasa A wymaga obecności klasy B podczas kompilacji. Klasa A jest nazywana klientem natomiast klasa B – usługą. O zależnościach między klasami pisał już Stefan Jungmayr. Jungmayr wyróżnił dwa rodzaje zależności:

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#] 3. Wyodrębniony interfejs klasy TabsService.

public interface ITabsService
{
    /// <summary>Gets active tab</summary>
    /// <returns>A presenter of a currently active tab</returns>
    ITabPresenter GetActiveTab();
}

Mając abstrakcje spróbujemy teraz uniezależnić komendę od konkretnej realizacji serwisu. Chcemy uniknąć odwołania do statycznej właściwości klasy TabsService i pozwolić innej klasie podjąć decyzję o konkretnej realizacji. Do tego celu stworzymy konstruktor, który jako parametr będzie brał implementacje interfejsu ITabsService. Ulepszoną realizację klasy RefreshQueryCommand wykorzystującą klasę TabsService poprzez interfejs przedstawiono w przykładzie 4.

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ć.

Debugger.Break();

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)

Spotkałem się dziś z małym problemem, który nie do końca wiem jak rozwiązać (zrobiłem pewne obejście, ale mi się nie podoba).

Mam tabelę dokumentów (D), tabelę elementów tych dokumentów (E) oraz tabelę pewnych dodatkowych informacji o tych elementach (R). Relacje wyglądają następująco: R --FK--> E --FK--> D.

A teraz zadanie:
- Należy scalić pewny zbiór dokumentów z (D) - nagłówki scalamy w jakiś sposób (to nas nie interesuje)
- W wynikowym dokumencie mają się znaleźć elementy (E) z wszystkich scalanych dokumentów
- Dodatkowe informacje z (R) mają zostać skopiowane i przypisane do odpowiednich elementów wynikowego dokumentu
- Dokumenty źródłowe mają pozostać w niezmienionej formie

Moja procedura iteruje sobie po dokumentach do scalenia. Najpierw scala nagłówek (D) kolejnego przetwarzanego dokumentu a następnie ma za zadanie skopiować elementy tego dokumentu do dokumentu wynikowego. Problem pojawia się z jednoczesnym skopiowaniem elementów (E) jak i informacji rozszerzonych (R). Chciałbym jednym insertem załatwić kopię elementów dokumentu a następnie drugim kopię informacji rozszerzonych. Niestety po krótkich poszukiwaniach nie znalazłem rozwiązania na pobranie identyfikatorów wstawionych wierszy (da się w ogóle?). Najszybszym rozwiązaniem byłby kursor, ale chciałbym uniknąć kolejnego.

Najpierw pomyślałem o modyfikowalnym widoku (ang. updatable view), tak aby jednym insertem wrzucić element i info rozszerzone, ale że nigdy tego nie robiłem, to szybko okazało się, że oczywiście można wstawiać wartości do takiego widoku, nawet jeżeli składa się z wielu połączonych tabel (w moim przypadku join między E i R), ale tylko w przypadku, gdy operacja wstawiania dotyczy kolumn tylko jednej z tabel (czyli już nie dla mnie). O pozostałych wymaganiach co do modyfikowalnych widoków można poczytać na stronie MSDN w podpunkcie o tytule updatable views. Można też zrobić triggera instead of insert dla tego widoku i w nim zająć się odpowiednim wstawianiem wartości, ale trigger to dla tego problemu chyba armata...

Może macie jakieś pomysły? Na pewno!

Doprecyzowanie zadania:
Kolumny (duże uproszczenie):
Tabela D: ID, Data
Tabela E: ID, FK_D, Kwota
Tabela R: ID, FK_E, Info

Dane:
Tabela D:
1, 12/01/2007
2, 13/01/2007

Tabela E:
1, 1, 23.4
2, 1, 1.1
3, 2, 45.32
4, 2, 1.0

Tabela R:
1, 1, 'Info'
2, 2, 'Ala'
3, 3, 'Info inne'
4, 4, 'Kot'

Po scaleniu dokumentów 1 i 2 z D powstają dodatkowe wiersze w odpowiednich tabelach (dla nagłówka datę bierzemy najwcześniejszą)
Tabela D:
3, 12/10/2007

Tabela E:
5, 3, 23.4
6, 3, 1.1
7, 3, 45.32
8, 3, 1.0

Tabela R:
5, 5, 'Info'
6, 6, 'Ala'
7, 7, 'Info inne'
8, 8, 'Kot'

Pracuję na SQL Server 2005. :)

C#: throw; vs throw e;

Jakoś ostatnio często wpadają mi do rąk różne teksty o wyjątkach w .Net. Z tego co da się zauważyć, to wyjątki, mimo swej prostej koncepcji, nie są do końca rozumiane i dobrze używane. Na szczęście są tacy ludzie jak Krzysztof Cwalina, którzy pomagają biednym programistom. Bardzo przydatne informacje na temat wyjątków można znaleźć na jego blogu. Ale nie o tym chciałem pisać...

Bardziej zaawansowanych programistów C# może nie zaskoczę, ale na pewno znajdzie się ktoś, kto nie do końca czuje różnicę (a może jej nie ma?).

Jeżeli złapiemy wyjątek w blok try-catch i mimo wszystko nie jesteśmy w stanie go do końca obsłużyć to powinniśmy go puścić dalej. Początkujący programista, aby ponownie zgłosić dalej ten sam wyjątek (ang. rethrow exception), zapewne napisze tak (zgodnie ze swoją intuicją):

private static void B()
{
    try
    {
        C();
    }
    catch (Exception e)
    {
        throw e;
    }
}

CLR w momencie, gdy zgłaszamy wyjątek pisząc throw new Exception() zapisuje ślad stosu wywołań funkcji (ang. stack trace) - można się do niego dostać za pomocą właściwości StackTrace. Funkcja, w której wyjątek został zgłoszony jest jego źródłem. Niestety ku zaskoczeniu wielu programistów (mojemu też, gdy się o tym dowiedziałem) throw e;, co prawda rzuca ten sam wyjątek, który został złapany, ale niestety ślad stosu zostaje nadpisany nowym śladem ze źródłem w miejscu tego wywołania :(. To nieuntuicyjne zachowanie jest przyczyną późniejszych problemów podczas debugowania ponieważ nie znane jest rzeczywiste źródło błędu. Dlatego należy pamiętać aby nigdy nie rzucać wyjątków w ten sposób!

Przykładowo rozważmy następujący program:

static void Main(string[] args)
{
    int w = 1;
    A();
}
private static void A()
{
    int w = 2;
    B();
}
private static void B()
{
    try
    {
        int w = 3;
        C();
    }
    catch (Exception e)
    {
        throw e;
    }
}
private static void C()
{
    int w = 4;
    D();
}
private static void D()
{
    int w = 5;
    throw new Exception("The method or operation is not implemented.");
}

W wyniku jego uruchomienia dostaniemy następującą informację:

Wyjątek nieobsłużony: System.Exception: The method or operation is not implemented.
   w ConsoleApplication1.Program.B() w D:\ConsoleApplication1\ConsoleApplication1\Program.cs:wiersz 30
   w ConsoleApplication1.Program.A() w D:\ConsoleApplication1\ConsoleApplication1\Program.cs:wiersz 18
   w ConsoleApplication1.Program.Main(String[] args) w D:\ConsoleApplication1\ConsoleApplication1\Program.cs:wiersz 12

Rzeczywiście, niepoprawne ponowne rzucenie wyjątku w metodzie B() skutkuje obcięciem śladu stosu. Zatem jak sobie z tym poradzić? Do tego właśnie służy użycie throw; bez parametru. Jeżeli teraz zmodyfikujemy odpowiednio metodę B() to sytuacja się odmieni.

private static void B()
{
    try
    {
        C();
    }
    catch (Exception e)
    {
        throw;
    }
}

Wynik uruchomienia jest następujący:

Wyjątek nieobsłużony: System.Exception: The method or operation is not implemented.
   w ConsoleApplication1.Program.D() w D:\ConsoleApplication1\ConsoleApplication1\Program.cs:wiersz 43
   w ConsoleApplication1.Program.C() w D:\ConsoleApplication1\ConsoleApplication1\Program.cs:wiersz 37
   w ConsoleApplication1.Program.B() w D:\ConsoleApplication1\ConsoleApplication1\Program.cs:wiersz 30
   w ConsoleApplication1.Program.A() w D:\ConsoleApplication1\ConsoleApplication1\Program.cs:wiersz 18
   w ConsoleApplication1.Program.Main(String[] args) w D:\ConsoleApplication1\ConsoleApplication1\Program.cs:wiersz 12

Widać zatem, że ślad stosu nie został obcięty i łatwo odnaleźć prawdziwe źródło błędu. Myślę, że nie trzeba nikogo zachęcać do takiego właśnie obsługiwania wyjątków. To może nam tylko usprawnić pracę. Różnicę, o której tu mowa, najlepiej widać na przykładzie kodu MSIL. Dla pierwszego przypadku mamy:

L_000f: ldloc.1
L_0010: throw

Natomiast dla drugiego:

L_000e: nop
L_000f: rethrow

Jak łatwo zauważyć MSIL ma dwie osobne instrukcje. Jedna - throw - służy do zgłaszania wyjątków a druga - rethrow - do ponownego zgłaszania wyjątków. Twórcy C# skondensowali je jednak do jednego słowa kluczowego, co czasami rodzi problemy.

Chciałbym jeszcze zauważyć jedną bardzo ciekawą rzecz. Co prawda wywołanie throw; zachowuje ślad stosu to jednak ciekawy jest sposób w jaki to robi. Otóż z powyższych rozważań można by było wywnioskować, że powyższe wywołanie zachwuje się tak jakby wyjątek w ogóle nie został złapany. Otóż nie! Wyjątek ten został złapany a co więcej ma to swoje odbicie w śladzie stosu. Tak naprawdę to sam ślad stosu jest obcinany a zachowywana jest tylko jego pełna tekstowa reprezentacja (sic!). Zatem to co widzieliśmy w powyższych przykładach jest tylko zapisem śladu stosu. Tę sytuację najlepiej zobaczyć uruchamiając dwie powyższe aplikacje w trybie debug.

Wyjątek po uruchomieniu pierwszej wersji:


Wyjątek po uruchomieniu drugiej wersji:


Na załączonych obrazkach widać, że używając throw; rzeczywiście zachowujemy ślad stosu, ale gdy spojrzymy na okno rzeczywistego śladu stosu to okaże się, że kończy się on na metodzie, która złapała i ponownie rzuciła ten sam wyjątek. Zatem nie mamy możliwości pójścia w górę stosu i dotarcia do rzeczywistego źródła wyjątku. Nie mamy też dostępu do żadnych informacji kontekstowych takich jak zmienne i parametry tych wywołań, które zostały ucięte.

Można się zastanawiać jak poprawnie obsługiwać wyjątki. Ja myślę, że:

• Przede wszystkim należy używać throw; zamiast throw e;
• Po drugie jeżeli nie obsługujemy wyjątku to nie ma sensu stosować bloku try-catch i ponownie rzucać tego samego wyjątku bez żadnej obsługi.

Trzymając się tych wytycznych debugowanie będzie przyjemniejsze.

Debugger i atrybuty, czyli jak usprawniać sobie codzienną pracę

Każdy programista pewną część swojego życia spędza z... debuggerem ;) Chyba zgodzicie się ze mną, że jest to bardzo przydatne narzędzie. Gdy pojawia się jakiś błąd i nie do końca wiemy co w trawie piszczy to odpalamy go i linia po lini weryfikujemy nasz program. Czasami jednak debugowanie może być uciążliwe... Pokażę kilka atrybutów, którymi możemy podpowiadać debuggerowi.

Zaglądanie do getterów, które podajemy jako parametry wywołania metody.

Najczęstszym problemem, który napotykam podczas debugowania to denerwujące wskakiwanie debuggera do getterów właściwości, które przekazuję w wywołaniu metody. Zwykle taki getter nie ma żadnej dodatkowej logiki tylko zwraca wartość prywatnego pola. Mając metodę z kilkoma tak podanymi parametrami łatwo się zgubić. Wiele razy w pośpiechu wciskałem F10, żeby wyskoczyć z tego gettera i okazywało się, że nacisnąłem o jeden raz za dużo i ominąłem wywołanie metody (sic!). Żeby było śmieszniej zwykle zdarza mi się to przy ostatnim parametrze metody! Na szczęście jest na to ratunek. W System.Diagnostics znajduje się atrybut DebuggerStepThroughAttribute, który zaaplikowany do metody lub właściwości karze debuggerowi ominąć oznaczony element i zatrzymać się po jego wykonaniu :) Zatem naszą znienawidzoną właściwość wystarczy udekorować:

private string _myProperty;
public string MyProperty
{
    [DebuggerStepThrough]
    get { return _myProperty; }
}

Tak oznaczonej właściwości już nie zobaczymy pod czas debugowania :D.

Przeglądanie zawartości złożonych obiektów

Czasami budujemy złożone klasy. Mogą to być na przykład takie zawierające wewnętrzne listy bądź też całkiem proste, z których budujemy większe struktury (np. węzły drzewa). Debugując taką klasę mamy utrudnione zadanie ponieważ musimy rozwijać różne elementy, żeby w końcu zobaczyć co zawiera ta wewnętrzna lista, albo zaglądać do elementów wgłąb tak jak to ma miejsce przy debugowaniu drzew. Przykładowe debugowanie drzewa binarnego wygląda tak:



Jak widać na załączonym obrazku wyciągnięcie wartości, które nas rzeczywiście interesują, czyli wartości w poszczególnych węzłach, jest trudne. Obraz jest zaciemniony przez inne pola. Istnieje jednak sposób, aby ułatwić sobie życie - atrybut DebuggerTypeProxyAttribute. Za jego pomocą możemy określić proxy, które będzie wyświetlanie podczas debugowania. Klasę proxy definiuje się bardzo łatwo. Może to być dowolna klasa, która posiada konstruktor przyjmujący parametr typu klasy, którą opatrzymy tym atrybutem. Podczas debugowania to klasa proxy będzie wyświetlana, czyli zobaczymy to, co w niej zdefiniujemy. W przykładzie z drzewem zdefiniowałem sobie taką klasę i dodałem do niej publiczne pole InOrder, które zwraca wartości drzewa właśnie w takim porządku:

[DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
public string[] InOrder
{
    get
    {
        List<String> result = new List<string>();
        GetInOrder(this._node, result, "");
        return result.ToArray();
    }
}

Należy tutaj zauważyć kolejny pomocny atrybut. DebuggerBrowsableAtribute służy do podpowiadania debuggerowi jak wyświetlać dane pole. Do dyspozycji mamy trzy wartości: Collapsed - element będzie zwinięty, Never - element nie będzie pokazywany oraz RootHidden - element nie będzie pokazywany, ale zamiast niego zostaną wstawione jego podelementy. W powyższym przykładzie ukryłem element InOrder, aby od razu wyświetlały się elementy listy, którą zwraca. W taki oto sposób debugowanie stało się o wiele prostsze:



Jak nie trudno zauważyć zawartość drzewa jest banalna do odczytania.

Wyświetlanie złożonych obiektów

Ostatnim atrybutem, o którym chciałem jeszcze wspomnieć jest DebuggerDisplayAttribute, który służy do definiowania napisu, który będzie wyświetlany dla złożonego elementu (klasy). Aplikując go podajemy również napis, który będzie wyświetlany. W tym napisie możemy odwoływać się do właściwości obiektu poprzez {Property}:

[DebuggerDisplay("Val: {Value}, Desc: {Description}")]
class SimpleClass
{
    private int _value;
    public int Value {...}
    private string _description;
    public string Description {...}
    public SimpleClass(int value, string description) {...}
}

Dzięki niemu nasza klasa będzie widoczna w debuggerze w następujący sposób:



Przedstawiłem tu techniki, z których korzystam na co dzień. Może i wam się przydadzą. :)
W załączniku zamieściłem przykładowy program dla ciekawskich.

Jak wyświetlić okno aby okno obecnie posiadające focus nie straciło go?

Zadanie (Windows Forms):

Ostatnio spotkałem się właśnie z takim problemem. Chciałem zaprogramować coś a'la ToolTip, który będzie mi się pokazywał nad moim polem tekstowym i w którym będę mógł umieszczać swoje informacje. Okazało się, że sprawa nie jest tak oczywista jak mogłoby się wydawać. Oczywiście zacząłem od ustawienia drugiej formatki jako TopMost, żeby zawsze pojawiała się na wierzchu. Największy problem polegał na zabraniu (albo najlepiej nie daniu) otwieranemu oknu focusa.

Pierwsze znalezisko - ale niestety nie rozwiązuje problemu do końca.
Dowiedziałem się, że implementując formatkę (dziedzicząc po Form) można nadpisać właściwość ShowWithoutActivation.

protected override bool ShowWithoutActivation
{
    get { return true; }
}

Jeżeli to zrobmy i zwrócimy true to okno będzie otwierało się bez focusa. Fajnie, już myślałem, że sprawa załatwiona. Niestety okazuje się, że opcja ta nie działa jeżeli okno ma ustawioną właściwość TopMost na true :(. W komentarzu na MSDN znalazłem, że aby podobny efekt uzyskać z oknem TopMost to należy skorzystać bezpośrednio z API Windowsa.

Druga wersja - tym razem rozwiązująca zadanie.
Po kolejnych kulku minutach na Googlach znalazłem to czego szukałem.

[DllImport("User32.dll")]
public extern static int ShowWindow(System.IntPtr hWnd, short cmdShow);

Wywołanie tej metody z uchwytem do pokazywanego okna i z parametrem cmdShow = 4 (SW_SHOWNOACTIVATE) załatwia sprawę. Okienko ładnie się pokazuje i nie dostaje focusa. Great! :)

W załączniku umieściłem przykładową aplikację, która pokazuje omówione tu techniki. Symuluje ona edycję tekstu w polu tekstowym oraz wyświetlanie okien pomocniczych. Wciskając kombinacje klawiszy CTRL + [Z, X, C] otwierać będą się kolejno: okno z TopMost = true przy użyciu standardowej metody Show, okno z ustawionym TopMost = true, ale za pomocą metody ShowWindow oraz okno z TopMost = false z nadpisaną właściwością ShowWithoutActivation zwracającą true.

Jeżeli jesteście ciekawi to zerknijcie sobie.

Konkurs Enterprise Library – Exception Handling (EHAB)

W zeszłym tygodniu mieliście okazję przeczytać o Logging Applicatinn Block i poznaliście pierwsze zadanie konkursowe. Dziś kontynuacja konkursu!

Refaktoryzacja do Exception Handling Application Block

W każdej aplikacji, małej i dużej, mogą pojawić się sytuacje wyjątkowe. Prosta operacja dostępu do pliku może się zakończyć kilkoma różnymi problemami. Wyjątki od samego początku tworzenia aplikacji towarzyszą każdemu programiście. W prostych aplikacjach, nie posiadających struktury warstwowej, zarządzanie wyjątkami nie sprawia wielu problemów. Jeżeli jednak mamy do czynienia ze skomplikowanym systemem o strukturze warstwowej, być może rozproszonym, oraz dużą ilością kodu źródłowego to może okazać się, że zadanie to nie jest trywialne. Aplikacja taka będzie wykonywała wiele różnych operacji, które mogą się zakończyć sytuacjami wyjątkowymi. Operacje te będą wykonywane w różnych warstwach systemu. Nie jest też powiedziane, że w każdej warstwie wyjątki mają być traktowane tak samo.

Rozwiązania dla tych wszystkich przypadków dostarcza nam Exception Handling Application Block.

Uzasadnienie

EHAB to jeden z komponentów potężnej biblioteki znanej pod nazwą Enterprise Library. Jest przeznaczony do spójnej i kompleksowej obsługi sytuacji wyjątkowych w dowolnym systemie. Za jego pomocą można obsługiwać wyjątki we wszystkich warstwach architektonicznych aplikacji. Tak jak i inne bloki tak i EHAB posiada jeden scentralizowany punkt (plik konfiguracyjny), w którym można definiować strategie przetwarzania wyjątków dla całej aplikacji, bez konieczności jej ponownej kompilacji.

Definiowanie strategii obsługi wyjątku jest bardzo proste. Podstawowym elementem konstrukcyjnym są tak zwane exception handlers. Wraz z biblioteką dostarczono kilka z nich, które są najczęściej wykorzystywane podczas obsługi błędów:

• Wrap Handler – pozwala na opakowanie obsługiwanego wyjątku w wyjątek innego typu. Oryginalny wyjątek jest zachowywany w polu      InnerException nowego wyjątku.
• Replace Handler – zastępuje obsługiwany wyjątek nowym wyjątkiem.
• Logging Handler – pozwala na zapisanie wszystkich informacji dotyczących wyjątku.
• Fault Contract Exception Handler – jest przeznaczony do obsługi wyjątków w WCF.

Definiowanie zaczynamy od określenia co najmniej jednej wytycznej (ang. policy) dotyczącej obsługi konkretnych błędów. Zestaw wytycznych definiuje się w zależności od potrzeb. Dla danej wytycznej definiujemy zbiór typów wyjątków, dla których chcemy określić sposób ich obsługi. Następnie dla każdego typu wyjątku definiujemy zestaw (ciąg) exception handlers, które będą wykorzystywane do obsługi danego wyjątku. Należy tu wspomnieć, że exception handlers są łączone w ciąg i wykonywane jeden po drugim, a wynikiem obsługi wyjątku jest wynik uruchomienia ostatniego handlera.

Wywołania EHAB mają zastąpić typowy kod, który pojawia się w blokach catch. Dzięki temu programiści nie muszą powtarzać tego samego kodu (np. logowania informacji o wyjątku) w wielu miejscach systemu. EHAB dostarcza im spójnego mechanizmu pozwalającego na łatwą konfigurację. Przykładowe użycie wygląda następująco:

Kod. 1 – obsługa wyjątku za pomocą EHAB
try
{
    // Run code.
}
catch(Exception ex)
{
    bool rethrow = ExceptionPolicy.HandleException(ex, " Data Access Policy");
    if (rethrow)
        throw;
}

Jak łatwo zauważyć, programista w trakcie tworzenia funkcji nie musi rozróżniać typów wyjątków, które może zgłosić wywoływany fragment kodu. Wystarczy, że wykorzysta pojedynczą klauzulę catch i w niej przekaże obsługę błędu do EHAB, a ten na podstawie konfiguracji odpowiednio obsłuży podany wyjątek.

Sposób wykonania

Refaktoryzacja do EHAB jest w moim odczuciu dość prosta i mechaniczna. W systemie, który będziemy poddawać refaktoryzacji znajdziemy wiele bloków try catch. To one będą głównym punktem naszego zainteresowania. Wprowadzanie EHAB wygląda następująco:

1. Dodaj odpowiednie referencje do projektu oraz przygotuj plik konfiguracyjny.
2. Zlokalizuj wszystkie miejsca, w których obsługiwane są wyjątki.
3. Dla każdego z tych punktów:
   1. Jeżeli potrzeba wprowadź nowe typy wyjątków.