Domain Driven Disaster

Przygotowania do prezentacji o DDD na LJUG w toku. Tymczasem mamy niecodzienną okazję aby zobaczyć jak w praktyce możne wyglądać projekt, którego jednym ze szczytnych założeń było podążanie za DDD.

Dziś pierwszy (i mam nadzieję, że nie ostatni) post z gatunku gościnnych.

Jako pierwszego mamy zaszczyt gościć tajemniczego Malory z krainy deszczowców, który podzieli się doświadczeniami z dużego, zagranicznego projektu. Projektu, w którym niestety nieco rozminięto się z filozofią DDD, TDD i Agile:

<post_goscinny>
Przyjemność bycia częścią projektu napędzanego czystym agilem (iteracje mamy, lecz do Agile nadal daleka droga), z domieszką domain driven, test driven, i ogólnie driven skłonił do podzielenia się kilkoma refleksjami. Tym gościnnym postem u Sławka podzielę się refleksjami o dysonansie miedzy filozofią którą niosą ze sobą ddd, Agile, TDD a praktyką... czyli Projektem.

O ddd Sławek pisał tutaj już nie raz i każdy z czytelników mniej lub bardziej "czuje' o co w ddd chodzi. Esencja to słowa z ddd.org: "ddd is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains". Nic dodać, nic ująć. Koncepcja a raczej filozofia spojrzenia na problem, na domenę. A w praktyce? Bywa różnie. Brak zrozumienia idei którą niesie ze sobą ddd, i twarde (beton) myślenie przez pryzmat aplikacji CRUD driven (formularzyki), gwarantuje Monthego Pythona każdego dnia. Sam wybór ddd nie zawsze jest szczęśliwy bo jak wyraźnie wskazuje cytat: "complicated domain". Więc po co się męczyć, i udawać ddd gdy chcemy zrobić nakładkę na db? Efektem końcowym będzie i tak mieszanka anemicznych encji i a'la serwisów żonglujących encjami w górę i w dół. W praktyce ddd niebezpiecznie zbliża się do kilku „warstewek” klas delegujących wywołania metod z dao. I nie ma w tym nic złego – to rozwiązanie dobiera się do problemu. Nie odwrotnie. Sama sytuacja w której kończymy z pustymi encjami (@Entity, nie żadne tam encje ddd) i serwisami wskazuje że coś jest nie tak. Fundament OOD jest prosty – odpowiedzialność a get/set to chyba jednak trochę za mało...

Siłą napędową ddd to domena, co w odniesieniu do projektu oznacza eksperta domeny, będącego światłem w tunelu dla zespolu. Jako ze projekt nie zawsze ma domain eksperta - bywa śmiesznie. Developerzy to cwani ludzie i dadzą radę, ale to raczej Developer Driven Design (co oczywiście nie jest złe.. ale zależy od doświadczenia zespołu...). W przypadku bogatej domeny, bez pomocy eksperta wątpliwe jest stworzenie nawet poprawnych zrębów domeny, nie wspominając nawet o niuansach i bliższym nakreśleniu relacji w domenie. Pora teraz na agile (fonetyka naszego rodzimego języka, nie żaden tam edżajl).

Skomplikowana domena powoli ewoluuje, nieraz zamiast ewolucji doświadczyć możemy rewolucji, gdy powolny knowledge crunching zaowocuje przełomem w spojrzeniu na domenę. I czy nie jest to "Responding to change over following a plan" który niesie ze sobą agile manifesto? W tym momencie przypomina mi się pytanie podczas jednego z pierwszych spotkań (spotkanie a raczej meeting jest nieodzownym elementem każdego poważnego agile projektu), a mianowicie "kiedy dostaniemy skończony model domeny?". Hmm - odpowiedź była prosta: nigdy. Po czym zaczęło się wyjaśnianie (okraszone nerwowymi spojrzeniami "góry"), że to nie waterfall. Same iteracje nie sprawią, że będziemy Agile. Do tego potrzeba tzw. bigger picture i zmuszenie całego zespołu (łącznie z managementem) do innego spojrzenia na problem. Iteracje i milestony mogą być jednak wystarczającą dawką agilu. O tym, że to wymagania napędzają development niekoniecznie się pamięta. Zresztą, bywa w niektórych projektach że wymagania odpowiadają poziomem testom (assertTrue(true)); //FIX LATER, its friday, 4 o'clock ). Raz zrobiony task (zrobiony w stylu general concept, bo jak inaczej bez wymagań...) zostaje jako skończony i nie ma nawet mowy o refaktoringu pózniej... To przecież zbędne filozofowanie... W wyniku zostaje brązowa (flagowy kolor branży) papka kodu którą ktoś (nieszczęśnik, albo student, niewolnik IT) będzie miał przyjemność poprawiać. Domena zamiast ewoluować - kostnieje, zamiast odpowiadać na zmiany - napierdalamy aby zdążyć w terminie.

Ostatnim kawałkiem układanki jest TDD. Który doskonale wpasowuje się do mieszanki DDD i Agile. Domena powinna ewoluować, dojrzewać, i odpowiadać na zmiany. Tutaj pomocną rączkę wyciąga TDD. Pod warunkiem że napisane testy mają sens. W życiu bywa jednak rożnie, w praktyce testy nie zawsze testują. Mądrze napisane uspokajają sumienie i pozwalają pracować nad aplikacją. Pozwalają na eksperymentowanie i dają ujście wiedzy którą powoli team zdobywa. Testy trzeba jednak umieć pisać.. i mieć na nie czas. Z pierwszym bywa rożnie, na drugie niekoniecznie jest czas w schedule projektu. Efekt - każdy boi się panicznie dotknąć czegoś większego w domenie aby całość się nie rozleciała...

Na koniec link do doskonałej prezentacji o... samochodach. Obejrzyj i popatrz przez pryzmat naszej branży. Tutaj też są projektanci i inżynierowie. W tej branży jest miejsce na pasję, rzemiosło i jakość. Uwolnijmy się od brązu.



</post_goscinny>



//=======================================

Jak wiadomo najlepiej uczyć się na błędach:) Dobrze, gdy mamy okazję z dystansu przyjrzeć się cudzym:]
Potwierdzają się moje przemyślenia na temat metodyk Agile. Idea piękna, ale pod warunkiem, że mamy dojrzały i świadomy zespól profesjonalistów, którzy wiedzą co robią lub przynajmniej mogą poprowadzić duchowo resztę teamu.

Sama filozofia DDD o ile nie jest jakoś specjalnie wysublimowana to niestety posiada pewną barierę wejścia: podstawy OO - i nie mam tu na myśli składni dziedziczenia, lecz myślenie obiektami.

Nie ma rzeczy niemożliwych

/*Post rozpoczynający serię: żarciki branżowe*/

http://www.getacoder.com/projects/detect_loop_106243.html
...jak widać jest wielu śmiałków gotowych od ręki i za niewielkie pieniądze rozwiązać problem stopu.
Ba... nawet licytują się, kto zrobi to szybciej i taniej.

I nie straszny im dowód nierozwiązywalności; teoria jest dla filozofów - "because we can"!

//=======================

Tradycyjnie tu powinien pojawić się mój własny komentarz. Jednak jako, że dziś wyjątkowo post z przymrużeniem oka to tym razem oddam głos temu panu:

Stare Chińskie przysłowie: Jest czas na pracę i jest czas na zbieranie ryżu

Podobno to Hindusi odkryli system dziesiętny - Arabowie jedynie go rozpowszechnili (mając silne argumenty w dłoniach;).
Nieco mniej chlubnym osiągnięciem indyjskiej myśli jest na przykład biblioteka tagów JSP do integracji z JPA, na którą to niedawno przypadkiem się natknąłem. Zdaje się, że przyświeca jej motto "because we can!"

Stereotyp programisty Hindusa, który "nakłada gacie przez głowę" jest dosyć mocno rozpowszechniony i zakorzeniony ale wystrzegajmy się pychy.

Ciekawe studium hinduskiej mentalności znajdziemy w interesującej, lekkiej ale bardzo pouczającej książce Moja Praca Emigruje do Indii - A wszystko, co dostałem, to ta marna książka. Ale to tylko jeden z aspektów. Poznamy przede wszystkim globalne mechanizmy korporacyjne mające wpływ na niemal każdego z branży IT.

Chad Fowler zabiera nas w egotyczną podróż do Bangladuru, gdzie spędził 1.5 roku tworząc Software House dla jednej z amerykańskich korporacji.

Poznamy szereg kuriozów:
- na ogłoszenie o pracę odpowiada średnio kilkanaście tysięcy chętnych
- a mimo niemałego budżetu nie można sobie pozwolić na tych doświadczonych
- taksówkarz zna 5 języków
- a programista nie ma własnego komputera w domu

Każdy z 52 zgrabnych i wyważonych rozdziałów niesie w sobie pewien morał. Lokalny folklor jest jedynie pretekstem do przekazania metafory lub przesłania. Dostajemy zestaw gotowych strategii, uwag, ostrzeżeń i porad z zakresu szeroko pojętego samorozwoju i autopromocji. Kto się nie rozwija ten się cofa a zmiany są nieuniknione.

//=========================

Wymowa książki w naszym lokalnym kontekście nabiera jednak drugiego dna. Nie musimy obawiać się emigracji naszej pracy do Indii. Być może jesteśmy Indiami Europy:P

Understandability

Understandability - ostatnio modny termin. Znak, że oto kolejne pokolenie programistów/developerów/inżynierów oprogramowania (byle nie "informatyków"!) dorosło do przepoczwarzenia. Z kał-bojów i szambe-lanów babrzących się w cudzych (tudzież własnych) klasach z archiwum X chcieliby stać się szczęśliwymi profesjonalistami wiodącymi szczęśliwe życie wśród łatwych, prostych i przyjemnych linijek kodu.


Komentarze

#define TRUE FALSE
//Happy debugging suckers

Stara szkoła mówi aby 70% tekstu stanowiły komentarze. Tak aby po hipotetycznym usunięciu kodu można było go łatwo odtworzyć na podstawie ich treści.
W praktyce oczywiście nie ma czasu na twórczość o tej skali - zarówno podczas tworzenia jak i utrzymywania kodu. Poza tym wydaje mi się, że takie podejście zmienia niewiele:
- pisanie dobrych komentarzy jest sztuką jeszcze większą niż pisanie dobrego kodu (o czym dalej) - więc wiadomo czego możemy się spodziewać
- komentarz daje nam jedynie bardzo lokalny obraz sytuacji, aby uchwycić tak zwany biger pikczer potrzeba zdecydowanie czegoś więcej...

Ileż to razy bierzemy jakąś bibliotekę/framework (załóżmy, że rzetelnie okomentowane) i niestety nie możemy połapać się w gąszczu dziesiątek/setek klas. Przydałby się jakiś wizualny standard prezentowania ogólnej architektury konceptu. Pomocny byłby już choćby jakiś sposób uwypuklenia zastosowanych wzorców projektowych/architektonicznych.

Owszem jakimś rozwiązaniem jest narzędzie do reverse engineering, przy pomocy którego możemy sobie wygenerować UML. Ale co mi po gąszczu prostokątów jeżeli nie wiem, które są istotne, które stanowią core konceptu, a które jedynie szczegóły impl.


Kod samokomentujący się
Skoro i tak muszę pracować z kodem to fajnie byłoby gdyby był intuicyjny. Niedoścignionym wzorem na tym polu jest:
Epopeja poświęcona poziomowi inteligencji dzielnego Ryśka - spisana w tej oto abstrakcyjnej klasie RichardIsAFuckingIdiotControl.

To mój styl - nauczyłem się go analizując źródła Springa. Nie boję się opisowych nazewników klas czy metod mających po 30, nawet 50 znaków. To nie czasy dyskietek, gdzie od ilości literek zależało czy musimy żonglować nośnikami aby skompilować projekt.

Oczywiście gdy z sygnatury metody nie mogę wywnioskować co ona robi to nie powinienem zaglądać do środka - komentarz jest jak najbardziej wymagany.

W tym przypadku, podobnie jak w poprzednim również mamy problem z ogarnięciem ogólnej idei rozwiązania. Jednak niektórzy porządni rzemieślnicy zostawiają czasem wskazówki w nazwach - przykładowo przyrostki wskazujące na zastosowany wzorzec: xxxCommand, xxxStrategy, itp.


Zbiorowa inteligencja
Niektórzy postulują jakoby dobry kod to taki, gdzie czytamy to czego właśnie w tym miejscu się spodziewamy. W sumie trudno się nie zgodzić - pycha pomysł. Niestety utopijny ponieważ każdy programista jest inny. Każdy ma swój styl (albo i nie - o tym na koniec) i smak. Nie zapominajmy, że zawodnicy w teamie mają różne poziomy skillsów.

Oczywiście w różnorodności siła, ale świadczy to też o braku profesji w naszym fachu, braku elementarnych zasad rzemiosła - jesteśmy bandą indywidualistów (ale to temat na następnego posta).


Czas to pieniądz
Dobra metoda, to taka gdzie zrozumienie co i jak ona robi zajmuje nie więcej niż 5 minut - to jedno z częściej powtarzanych haseł. Miara równie rozmyta jak poprzednia. To co będzie oczywiste dla kodera turbo-ninja z silnym autyzmem, który w jednej półkuli kompiluje kod do rozkazów maszynowych nie będzie już takie dla studenta zarabiającego na piwko w PHP.


Z trochę innej strony...
Nierzadko spotkam się z sytuacją, w której programista nie wie jak nazwać klasę, metodę czy instancję. Albo nazwy pakietów - czy nie powinny wskazywać na "uporządkowanie myśli" i odzwierciedlać architekturę aplikacji? Niby szczegół prawda? Ot po prostu nie mam dziś weny. Zresztą co to za różnica? Kompilatorowi przecież jest wszytko jedno. Nazwę sobie Manager5, doStuff(String param1, String param2) albo x7.

Jest to jednak niepokojący syndrom - i mam tu na myśli coś gorszego niż rak mózgu;)

Ale żeby nie było, że sobie coś ubzdurałem, podeprę się najpierw autorytetem paru guru z naszej branży aby nie stać na grząskim gruncie własnych urojeń.

W 2006 r. niejaki Jarosław Rzeszótko znany również pod zabarwionym perwersją pseudonimem artystycznym "sztywny" wpadł na ciekawy pomysł. Zadał 9 (w większości) znamienitym programistom 10 pytań: Stiff asks, great programmers answer.

Ciekawych odpowiedzi udzielili panowie na pytanie:
"What do you think is the most important skill every programmer should posses?"
Istotne okazują się zdolności "miękkie", min: komunikacyjne, pisarskie, muzyczne.
Ciekawą - bo niemal ocierającą się o neuropsychologię;) - odpowiedź dał Dave Thomas:

I _have_ seen a strong correlation between people who have some music in their background and programming skills. I have no idea why, but I suspect that some of the areas of the brain that make someone musical also make them good at software development.

Linus Torvalds dla odmiany stawia na poczucie "smaku".


Do czego porównać kod, który będzie samoopisujący się, którego zrozumienie nie wymaga zbyt wiele czasu - ba, wręczy czytamy to czego się spodziewamy?
Dla mnie taki kod jest jak powieść. Kreujemy aktorów (klasy) o pewnych cechach osobowości (metody). Niektórzy są dwulicowi (interfejsy). Budujemy scenografię (warstwy, moduły) gdzie będzie rozgrywać się akcja. Nie jakieś śmietnisko, ale dobrze zorganizowany kompleks spójnych budowli. Dalej nie pozostaje już nic innego jak opowiedzenie ich historii, począwszy od stworzenia poprzez ew. reinkarnacje;) Bez zbędnych dygresji i wnikania w poboczne wątki - te nich dzieją się we wszechświatach równoległych dostępnych przez portale mangerów zdarzeń.

Werbalizowanie historii może wydawać się bzdurne, ale zastanówmy się co nam daje. Aby np zbudować metaforę musimy włożyć pewien wysiłek umysłowy. Wypowiedzi w języku naturalnym są obłożone szeregiem ograniczeń - szczególnie ważne są ograniczenia logiczne. Dzięki nim możemy wychwycić luki w naszym rozumowaniu, pokraczne modele, cieknące abstrakcje. Ograniczenia werbalne pomagają w ogarnięciu chaosu. Można je nazwać nieformalnymi regułami walidacji poprawności koncepcji.


//=======================

Ktoś kiedyś napisał, że programistów można podzielić na 3 grupy. Tych, który mają dobry styl, tych który mają zły styl i tych, którzy w ogóle stylu nie mają.
Ci drudzy nie są jeszcze straceni. Co prawda ich poczucie stylu jest złe, ale przynajmniej jakieś jest - przy pewnym wysiłku można je zmienić na dobre. Najgorsi są Ci, którzy w ogóle nie rozpatrują czegoś takiego jak styl - jest to poza ich zakresem pojmowania. Ci są straceni.

Risercz: DDD

W związku z natłokiem spraw nie mam czasu aby napisać coś bardziej sensownego na blogasku. Właściwie to problem nie tyle z samym czasem co z mózgiem obciążonym zbyt wieloma wątkami, co w rezultacie skutkuje zanikiem weny - czyli impotencją intelektualną (wszyscy pewnie znacie to uczucie nieprzyjemnego napięcia, które odbiera kreatywność).

Aby jednak podtrzymać aktywność ucieknę się do prastarego triku i wkleję trochę linków, które ostatnio sobie przyswoiłem, i które to uważam za godne zauważenia.

Będzie to jednocześnie pierwszy z nowej serii postów - raporty/streszczenia z riserczu.



Dziś będzie o (niespodzianka) Domain Driven Design. Dwa artykuły opisujące mniej lub bardziej techniczne aspekty DDD. Tak, wiem, że DDD to filozofia i technikalia nie są ważne, ale ktoś kiedyś jednak będzie musiał wziąć się do roboty i zaimplementować nasze prostokąty i strzałeczki;P


Na początek ciekawe kompendium technologiczne na temat domain driven DEVELOPMENT:
Domain Driven Design and Development In Practice.
wszyscy narzekają, że owszem DDD fajne jest, ale jak tak na prawdę podejść do projektu? W treści znajdziemy wiele ciekawych pomysłów i alternatywnych koncepcji.
Powyższy link jest co prawda Made in India, ale mimo tego jego treść jest rzetelna - poza tym marka infoq do czegoś zobowiązuje.


Dla odmiany teraz coś Made in Germany. Niestety odmiana ma charakter przede wszystkim jakościowy:/
Domain-driven design with Java EE 6
Oto jak kończy się aplikowanie prymitywnej platformy do zaawansowanej koncepcji - naiwna implementacja.

Pomysł bram (gate) może i ciekawy... Na pewno wygodny z punktu widzenia programisty. Mamy oto coś na kształt stanowego servisu, który ma w sobie entity managera w trybie rozszerzonym. Dzięki temu możemy sobie korzystać z lazy lodingu podczas ping-ponga pomiędzy klientem a serverem. Prawie jak konwersacje w seam:)
I czy w ogóle jest o co walczyć? Ile czasu zaoszczędzę posługując się Lazy Loadingiem zamiast napisać sobie Repo, które będzie używane przez agregat w celu pobrania składników tegoż agregatu? A co z wydajnością Lazy Loadingu:P
Podsumowując: życzę powodzenia przy nieco większej ilości użytkowników hehe

Na uwagę zasługuje jednak nowy termin, który próbuje się ukuć "persistent domain object (PDO)" - podoba mnie się to:)
PDO czyli Agregat w sensie DDD (posiada stan i odpowiedzialność - metody biznesowe), który dodatkowo ubabrany jest adnotacjami JPA. Czyli wreszcie dojrzewamy aby odejść od proceduralnego rozdziału struktry danych od algorytmów (encje/servisy).
Niestety taki agregat przesłany do warstwy UI ciągnie za sobą metody biznesowe, które nie powinny być dostępne w tej warstwie.
Jednym z rozwiązań jest stworzenie 2 stosów warstw - opisane na końcu tego nudnego posta, innym są mixiny z frameworki qi4j.

//==========================================

Na zakończenie ciekawa refleksja: http://www.infoq.com/interviews/domain-driven-design-eric-evans#view_10448. Nasze community nauczyło się wreszcie korzystać z podstawowych technik (które podobno istniały juz w latach 80 w Smalltalk) i wreszcie ukonstytuowały się pewne standardy z zakresu projektowania i architektury.

W skrócie: community java powoli kończy etap onanizmu technicznego i można zacząć skupiać się na problemach na prawdę istotnych.

Natomiast z komentarza tego znamienitego dinozaura http://www.infoq.com/interviews/domain-driven-design-eric-evans#view_10653 wynika, że już prawie dotarliśmy tam, gdzie community Smalltalk było w latach '80...

Lazy Loading a sprawa wydajności

Podążając za ciągiem skojarzeń: od przedwczorajszego DAO przez wczorajsze Lazy Loading dziś czas na aspekt wydajności podczas korzystania z maperów relacyjno-obiektowych. Właściwie to główne niebezpieczeństwo tkwi w tytułowym Lazy Loadingu.

Sprawa jest w sumie prosta - trzeba uważać co się robi i mniej więcej orientować się jak działa mapper. Nie trzeba wnikać nawet w aspekty implementacyjne Lazy Loadingu: klasy pośredników, które mogą być podstawiane do encji czy to poprzez manipulację byte codem czy w czasie generowania kodu źródłowego (jednak zainteresowanym polecam zgłębienie tematu - warto wiedzieć "jak oni to zrobili").

Niestety na żadnej ze stron domowych maperów zgodnych z JPA (Hibernate, OpenJPA, Kodo, TopLink) nie dopatrzymy się ani na głównej stronie, ani na żadnej innej wielkiego czerwonego napisu "UWAGA NA WYDAJNOŚĆ PODCZAS STOSOWANIA LAZY LOADING!". Nie uraczymy również zestawu paru prostych porad, które uchroniły by nas przed dramatycznym spadkiem wydajności. Czyżby nie wyglądało to zbyt marketingowo? Może autorzy sądzą, że ludzie tego nie zauważą i jakoś to będzie - kolejny bubel się przyjmie w społeczności:)

Problem wydajności jest stary jak Hibernate ale niestety jeszcze nie wszędzie uświadomiony. Jako przykład podam tę oto przypowieść.



Niezbyt_dawno, niezbyt_dawno temu w pewnej dużej organizacji strasznie mulił system wykorzystujący Hibernate. Ludzie ze swą wrodzoną skłonnością do tworzenia mitów szybko poradzili sobie z dysonansem poznawczym trapiącym ich mózgi: stworzyli sobie prosty system mitologiczny, który nakazywał im wierzyć, że ORMy tak po prostu mają. Po prostu ich magiczne właściwości powodują, że systemy spowalniają a odczyt danych z bazy jest hamowany jakąś niepojętą siłą. Ciemnotę dodatkowo potęgowała Kasta Adminów Baz Danych, mówiąc: "tak oto kończy się sprzeniewierzanie prastarej składni SQL. Nie chciało się wam niewierni pisać procedur i kwerend to teraz sczeźnijcie w piekle!".


Po wstępnych oględzinach okazało się, że w większości przypadków obarczonych bardzo niską wydajnością mamy do czynienia z klasycznym problemem występującym w ORMach z Lazy Loadingiem: n+1 Select Problem.

Istotę problemy wyjaśnię na przykładzie: Wyobraźmy sobie, że pobieramy listę obiektów klasy Person. Następnie iterujemy po tej liście i dla każdej osoby wołamy getAddresses() po to aby coś tam z adresami każdej z osób zrobić. Jeżeli zapytanie wygląda mniej więcej tak: SELECT p FROM Person p to mam rzeczony problem. Najpierw silnik persystencji wysyła do bazy jedno zapytanie w celu pobrania listy osób. Następnie dla każdej z n osób wysyła zapytanie o jej adresy. W sumie n+1 zapytań:) Pięknie nieprawdaż? Niestety musimy pofatygować się i napisać porządne zapytanie HQL (lub odpowiednie Criteria w Hibernate), które spowoduje dodżojnowanie adresów do osób tak aby wysłane zostało do bazy jedno zapytanie SQL. Niestety nieodzowne będzie dopisanie w HQL paru JOIN FETCH - a co za tym idzie korzystanie z Entity Managera przestaje być takie trywialne jak w tutorialach, pojawia się złożoność, którą warto hermetyzować w DAO/Repozytorium.

Należy uważać również na "utajony" wariant n+1 select problem. W powyższym przykładzie mamy sytuację, w której radośnie iterujemy sobie przy pomocy własnego kodu po osobach i grzebiemy w ich adresach. Może być też tak, że nasz własny kod jest OK, ale niefortunnie podepniemy naszą listę osób pod np jakiś komponent GUI (np h:dataTable w JSF), który ma wyświetlić osoby wraz z adresami i nieszczęście gotowe. Logika renderingu tabelki przeiteruje po osobach aby wyrenderować jej adresy. Wówczas mogą zdarzyć się 2 rzeczy:
- aplikacja się wywali z powodu LazyInitializastionException (lub jakiegoś innego wyjątku w zależności od dostawcy JPA - co zresztą uważam za skandaliczne) ponieważ najpewniej w warstwie widoku sesja będzie już dawno zamknięta
- jeżeli jednak stosujemy jakiś trik typu Open Session In View to wówczas ORM radośnie wygeneruje nam n+1 zapytań do bazy:)))

Pierwszy wariant (wyjątek) jest o tyle dobry, że przynajmniej zwróci czyjąś uwagę podczas devlopmentu i skłoni do napisania porządnego zapytania, które ładuje wszystkie dane w jednym podejściu. Drugi wariant działa więc jest szansa, że nitk nie sprawdzi co się dzieje po stronie bazy:/



Kolejna przypowieść. W tejże samej organizacji istniał inny system, który również niemiłosiernie mulił. Tym razem był to gruby klient do serwera więc lazy loading nie miał zastosowania. Encje przesłane na klienta nijak nie chcą nawiązać kwantowego kanału z procesorem serwera:/ W tym systemie również panowała mitologia. Kiedyś pewien magik podobno zrobił czary mary i LazyInitalizationException nie pojawiał się gdy na kliencie wołano łańcuszki get get get.


Po krótkiej analizie problemu okazało się, że tym razem przedobrzono w inną stronę. Prawie wszystkie powiązania pomiędzy obiektami były EAGER - czyli chciwe lub jak kto woli łapczywe. Skutkowało wyciąganiem połowy bazy przy każdym zapytaniu. O ile serwer bazodanowy dawał radę to wąskim gardłem okazała się transmisja zserializowanych danych. Wniosek znowu ten sam: niestety na skróty się nie da - trzeba się pofatygować i napisać porządne zapytania specyfikując co w jakim Use Case ma być podciągnięte. Niestety zakorzeniona mitologia i szargana opinia o ORMach pozostanie w organizacji na parę następnych pokoleń.

Przy okazji warto wspomnieć o kolejnej pułapce jaką szykuje na nas maper. Uwaga na powiązania typu n-1 lub 1-1 - czyli takie gdzie w klasie encji mamy pole klasy innej encji (np Person ma jeden Adres). Standard JPA zakłada, że wówczas powiązanie jest typu EAGER. Czyli pobierając z bazy osobę zawsze od razu wyciągniemy jej adres. Niestety odbywa się to zazwyczaj w osobnym zapytaniu. Czyli w przypadku pobierania listy osób mamy n+1 Select Problem:)


Żeby nie było, Lazy Loading może również przydać się w celu optymalizacji systemu.
Wyobraźmy sobie taki przypadek: Mamy klasę dokument, która zawiera szereg pół - w tym pole zawierając treść dokumentu: kilkadziesiąt stron A4 (pomińmy kwestię sensowności takiego projektu). Gdy chcemy zaprezentować listę dokumentów na GUI, która zawiera dajmy na to tytuł i datę to oczywiście zupełnie niepotrzebnie będziemy pobierać z bazy i przechowywać w aplikacji (choćby chwilowo) dziesiątki megabajtów tekstu. Jednym z paru rozwiązań ale najprostszym jest ustawienie leniwego ładowania kolumny z treścią. Gdy nie będzie potrzebne wówczas nie będzie ładowane z bazy.


//============================

Podstawą pracy z ORM jest konsola z logami. Podczas developmentu należy włączyć wyświetlanie generowanych poleceń SQL i nieustannie obserwować oczami swymi logi silnika ORM czy przypadkiem nie pojawia się na niej w pewnym momencie kilka/-dziesiąt/-set/-tysięcy zapytań. Oczywiście n+1 Select Problem możemy zauważyć na konsoli praktycznie tylko wówczas gdy napełnimy bazę większą ilością danych. Dla n=1 problemu raczej nie uraczymy.

W dobrym procesie produkcji softu jest czas na takie coś jak kontrola kodu - przeglądanie nowego kodu przez bardziej doświadczonych członków teamu (lub chociaż przez drugą parę oczu). Co powiecie na kontrolę konsoli? Pokaż misiu jakie zapytania do bazy generuje Twój kod.

Podsumowując dwie przytoczone przypowieści pozwolę sobie zacytować Franka Zappa: "Głupota ma pewien urok, ignorancja nie".

DAO a sprawa Lazy Loading

Wracając do wczorajszego tematu DAO rozwinę nieco kontekst mapowania relacyjno-obiektowego na przykładzie standardu JPA. Dokładnie - skupię się na głównym ficzerze każdego mapera zgodnego z JPA, czyli tytułowym leniwym (opóźnionym) ładowaniem zagregowanych w encji obiektów.

Niektórzy pewnie zastanawiają się czego znowu ten zgred się czepia. Przecież LL to taki fajny ficzer. Mamy sobie załadowany z bazy obiekt (i jeżeli sesja kontekstu perzystencji nie została zamknięta) to wystarczy zawołać na nim getXXX(), czary mary i pobrany przez getter zagregowany obiekt został podciągnięty z bazy oraz zapakowany do encji.

Wszystko fajnie, ale jeżeli korzysta się z tego z świadomie i w odpowiednim momencie. W przeciwnym wypadku mamy spore problemy z wydajnością. Ale o tym za w następnym poście. Ja mam z tym jeszcze pewien problem natury filozoficznej, który pojawia się gdy do naszej architektury wprowadzimy warstwę DAO (bez której jak bez ręki - co chciałem wczoraj wykazać)...

Zatem weźmy przykładowy interfejs DAO:

public interface PersonDAO{
  Person getPerson(Long id);
}

Standard... zwykłe DAO (nie czas teraz na Repozytorium z DDD), zwykły klucz (nie czas teraz na UID czy klasę kluczą w dobrym stylu DDD).

Dalej będzie oczywiście jedna z możliwych implementacji w JPA:

public class JpaPersonDAO implements PersonDAO{
  EntityManager em;
  Person getPerson(Long id){
    return (Person)em.find(Person.class, id);
  }
  ...
}

Też standard, bez żadnego generic DAO czy innych klas bazowych, bez wnikania w szczegóły wstrzykiwania EM. Nie w tym rzecz, chodzi tak jak wspomniałem o problem natury filozoficznej, mianowicie:
Co ja mam napisać w komentarzu metody getPerson() w interfejsie? (i od razy mówię, że banał typu "return returns person that has ID relevant do given id" mnie nie zadowala)

Aby w komentarzu napisać prawdę, całą prawdę i tylko prawdę musiałbym popełnić coś takiego (po polsku będę komentarz pisał - wybaczcie):

"
Metoda zwraca osobę o zadanym ID. Drogi programisto-użytkowniku klas implmentujących ten interfejs, wiedz ,że niniejszy interfejs zawirea z tobą kontrakt o następujących warunkach:
1. O ile korzystasz z implementacji DAO opartej o JPA to możesz się spodziewać tego, że:

1.a Niektóre klasy obiektów zagregowanych w zwróconej instancji osoby zostaną zastąpione przez klasy specyficznych pośredników (np PersistentBag w hibernate) więc niniejszy interfejs nie może zagwarantować Ci poprawnej pracy w środowisku rozproszonym (np aby wynik działa tej metody przesłać na zdalnego klienta musisz mu zapewnić odpowiednie biblioteki w odpowiednich wersjach).

1.b Być może masz dostęp do obiektów zagregowanych w zwróconej instancji. Na przykład do adresu (przez metodę getAddress). Zależy to od tego czy znajdujesz się w miejscu, w którym jeszcze obowiązuje sesja kontekstu persystencji. Jeżeli sesja będzie zamknięta, a ty będziesz brzydko się bawił z instancją person to dostaniesz np LazyInitializationException - ale tego w tym momencie nie mogę zagwarantować, gdyż zależy to od dostawcy (specyfiakcja JPA nic nie narzuca w temacie reagowania na zamkniętą sesję). Niestety niniejszy interfejs jest czystą abstrakcją dostępu do danych i nie mogę Ci zdradzić szczegółu na jakim dostawcy JAP będzie oparta implementacja tego interfejsu.

2. Jeżeli implementacja tego interfejsu nie będzie oparta o JPA (a np o dostęp do web service albo pliku XML) to wiedz, że dostępu do żadnych zagregowanych obiektów nie masz.

return osoba o zadanym ID, z którą ni cholery nie wiadomo co można na 100% bezpiecznie zrobić.
"

Ogólnie chodzi mi o to, że staroświeckie DAO i nowoczesny mechanizm Lazy Loadingu mają się nijak do siebie.

//==================================

Mamy tu do czynienia z bardziej ogólnym problemem: przeciekającą abstrakcją. Szczegóły techniczne mappera relacyjno-obiektowego (takie jak lazy loading, problem z wygasłą sesją) literalnie wyciekają z interfejsu DAO, który powinien być czystą abstrakcją dostępu do danych niezależną od jakiś maperów. Innymi słowy klient (kod) interfejsu DAO musi być niestety świadomy pewnych "wyciekających" mechanizmów stojących za jedną z jego implementacji. Nie może jej traktować jako czarnej skrzynki, która robi to co ma robić - i robi to dobrze.