Warstwa domeny w Domain Driven Design jest prawdziwą wisienką na torcie. Powinniśmy dbać o nią, aby zawsze była czysta. Dziś przedstawię Wam kilka heurystyk, których stosowanie spowoduje, że Wasza domena nabierze barw 🙂
Aby nasz kod mógł być czysty, twórcy frameworków muszą się nieraz porządnie nagimnastykować. Dobrym tego przykładem jest biblioteka Doctrine, która skrywa wiele bardzo ciekawych technik. Jedną z nich jest wykorzystywanie tzw. klas Proxy, którym poświęcam dzisiejszy wpis.
Encje są bardzo kontrowersyjnym tematem. Z jednej strony, są to klasy, które żyją niejako w odseparowaniu od Doctrine. Z drugiej strony, to Doctrine zarządza tym, kiedy, gdzie i jak encja powstaje. Dzieje się tam pod spodem trochę magii, którą, w dzisiejszym wpisie, postaram się nieco prześledzić.
System zdarzeń jest jednym z fajniejszych wzorców projektowych. Nie dość, że jest on zgodny z SOLID (bo rozszerzamy), to dodatkowo jest on łatwo testowalny. Niestety, czasami możemy przeszarżować, zwłaszcza, jeżeli chodzi o nasłuchiwanie zdarzeń, które oferuje nam Doctrine 2. Poznajcie kilka wskazówek, dzięki którym (mam nadzieję) pozbędziecie się potencjalnych problemów w przyszłości.
Podczas tworzenia aplikacji biznesowych, nie sposób nie poruszyć tematu aktualizacji bazy danych – elementu, z którym spotykamy się w codziennej pracy. Niezależnie od typu środowiska, zawsze trafimy na temat migracji bazy danych. Na szczęście Doctrine posiada specjalnie do tego wyspecjalizowany mechanizm, którego najważniejsze elementy poruszymy w tym wpisie.
Doctrine, jako bardzo zaawansowane narzędzie, posiada bardzo dużo mechanizmów, które należałoby poznać zarówno od strony teoretycznej jak i w boju. Okazuje się, że niektóre z tych funkcjonalności – pomimo, że służą do podobnych celów – mogą się wzajemnie wykluczać. Niestety, niezbyt wiele osób wie, że właśnie tak jest z funkcjami Doctrine Schema oraz Migration. Dlatego właśnie powstał ten wpis.
We wpisie o Lazy Loadingu wspomniałem, aby pobierać wszystko, czego potrzebujemy, na raz. Słowem-kluczem tutaj są słowa „czego potrzebujemy”. Z perspektywy działania aplikacji wydaje nam się, że do konkretnych operacji potrzebujemy pełnego zestawu danych. O tym, że czasami można taniej – jest dzisiejszy wpis.
Najsłabszym ogniwem większości aplikacji jest baza danych. Praca na domyślnej konfiguracji Doctrine tylko pogłębia ten problem. Znajomość podstawowych procesów optymalizacji oraz zasady ich działania powinny być wiedzą ogólnodostępną. Dlatego dziś poruszymy klasyka, jakim jest Doctrine Eager fetch mode, czy jak kto woli – Doctrine Eager loading.
Większość świeżych programistów, którzy pytają tych starszych o porady, słyszą: „Ucz się Symfony, Doctrine i pisz testy”. A młodzi przyjmują to za świętość i uczą się. Znają podstawowe pojęcia, po czym wchodzą na projekt, napiszą endpoint dla dużego zestawu danych i… całość wykonuje się w 13 sekund. Ta historia, choć nieco przeze mnie ufarbowana, wydarzyła się całkiem niedawno. I z chęcią podzielę się z Wami kilkoma szczegółami oraz wnioskami z tej sprawy 🙂
Niezależnie od tego, z którego frameworka korzystamy, zawsze powinniśmy promować własną refleksję ponad wszystko. Nawet pracując w Symfony, który uchodzi za najlepsze narzędzie w swojej kategorii, jesteśmy w stanie stworzyć niefajny kod. Dziś poruszymy temat reprezentatywnego przykładu, który potwierdza tą tezę.