Niedawno sam przeczytałem Clean Code i podobnie jak w przypadku krzyczaka cytowany fragment zburzył mój światopogląd. Tym bardziej, że z railsami jestem dopiero na początku drogi, a pojęcie “fat model” zdaje się trzymać mocno (może to kwestia wciąż dojrzewającego środowiska ;)).
Czy coś się zmieniło przez rok (ostatni post w temacie lipec 2010), czy może rozwiązanie Engine Yardu jest wciąż aktualne i najbardziej eleganckie?
Zawsze warto pisać czysty kod
p.s.
Jak ktoś nie czytał, to dołączam się do polecających książkę Wujka Boba!
Artykuł z Engine Yartu warto chyba uzupełnić artykułem o DCI z bloga Andrzeja Krzywdy. Muszę przyznać, że korzystam z tego w jednym projekcie i działa to całkiem obiecująco.
Wybaczcie, że się wtrące (widząc osoby biorące udział w tej dyskusji to moja widze o Railsach nie umywa się do waszej), ale myśle, że dzięki takiemu podejściu, że logika biznesowa jest w oddzielnych klasach niż modele bazy danych po części uniezależniamy się od bazy danych. Tzn proście jest przejść między różnymi mapperami.
Przykład:
W aplikacji wykorzystujesz dwie bazy danych, szybką bazę danych i drugą wolniejszą. W tej pierwszej przechowywane są wpisy, które wymagają szybkiego czasu odpowiedzi, natomiast gdy obiekt nie jest juz potrzebny, można go przenieść do wolniejszej bazy danych. Gdyby modele bazy danych były oddzielone od logiki biznesowej, wtedy dla danego obiektu mógłby istnieć tylko jeden model z logiką biznesową.
Być może, tylko po co? Wydaje mi się, że zjawisko przeskakiwania pomiędzy data mapperami jest na tyle rzadkim zjawiskiem, że nie warto wprowadzać dodatkowej wersji abstrakcji tylko dla tego celu.
Ale Wafcio poruszył fajną możliwość: mappery możesz wtedy łatwiej zmienić, a mappery jak najbardziej zmieniasz – jeśli zmieniasz silnik bazodanowy na taki o zupełnie innej filozofii. Pozwala to mniej boleśnie przenieść część danych, konkretnie tę “volatile” (niekrytycznych, łatwo odbudowywalnych, o częstym dostępie – czy to odczycie, czy zapisie) część, do innego silnika (mongodb, couch, redis itd.).
