Logica Bussinesowa - przydatne gemy, praktyki?

Cześć,
W pracy odpowiadam za kilka prostych aplikacji Webowych(RoR 4 i 5) do wewnętrznego użytku dla pracowników firmy.
Co to dużo mówić - pojawiają się nowe funkcjonalności, modele strasznie puchną, a sporo operacji po prostu nie pasuje do “lib” czy concerns. Możecie polecić jakieś gemy, pomagające zorganizować kod?
Ja obecnie korzystam z interactorów i dekoratorów.

  • Interactory(https://github.com/collectiveidea/interactor) - rozumiem je jako odpowiedniki serviców. Obawiam się trochę wpływu na wydajność - być może niesłusznie uważam że tworzenie nowych obiektów do zadań nie zawsze ma sens. Czy np. opłaca się zmieniać defaultowe MVC dodając servicy, tak że np. w trakcie save/create większość logiki wykonuje serwisy, a w modelu zostają tylko validatory ? (coś ala schemat Java Spring). I czy stosujecie jakieś alternatywne gemy/praktyki ?

  • Decoratory - z założenia mają chyba pomagać w ogarnięciu helperów (np. zmiana formatu daty itd.). Jakie są najlepsze gemy/biblioteki przeznaczone do odchudzenie modelu z duże liczby callbacków/validatorów? Ja obecnie rozbijam po prostu model na moduły według funkcjonalności i includuję. Czasami wspomagam się Concernami (łatwe deklarowanie callbacków i validatorów) ale to chyba nie jest dobra praktyka.

  • Zależności między modelami - jakieś bardziej globalne rozwiązanie względem callbacków ? Chodzi głównie o sytuację struktury drzew np. rodzica-dzieci wewnątrz jednego modelu. Kiedy rodzić dostaje określonego updata, należy też zaktualizować część kolumn u dzieci. Drugim przykładem mogą być różne modele w relacji jeden do wielu. Gdy “jeden” zostaje zaktualizowany, należy zweryfikować (i ewentualnie zmodyfikować)wszystkie powiązane z nim obiekty. Modyfikacja może być zarówno zwykłą operacją matematyczną, odczytem z pliku tekstowego, jak i GETem do zewnętrznego API.

ServiceObjecty :slight_smile:

W zasadzie to gem interactory dostarcza do nich szkielet. Istnieją jakieś alternatywy (poza tworzeniem z palca własnych klas) ?

Ostrożnie z tymi ServiceObjectami. :wink:

Jeszcze jeden ciekawy artykuł:

https://medium.com/@Killavus/what-advice-rules-i-may-give-to-junior-developers-about-the-ruby-on-rails-app-design-6a129bd86b85.

1 Like
1 Like

Teraz 2 sensowne podejścia są:

  1. http://trailblazer.to

  2. http://dry-rb.org/gems/dry-transaction/ i cała reszta z dry-rb.

Przede wszystkim nie opierać się na callbackach, walidacjach i większości ‘feature’ z active recorda. To powinna być tylko warstwa pośrednicząca pomiędzy bazą danych a aplikacją, a nie miejsce gdzie pakujemy jakąkolwiek logikę.

2 Likes

@b0ni - dzięki. Trailblazer wygląda mega :slight_smile:
Zacznę sobie coś w nim klepać.
A czy ma sens podejście “mieszane” - co przez to rozumiem: dla jakichś prostych modeli z minimalną logiką zostawić ją klasycznie i korzystać z Active Record, dopiero gdy wzrasta stopień komplikacji przejść na TrailBlazera ?

Jeśli piszesz coś nowego i wiesz, że będzie duże, to konsekwentnie używaj trb. Jeśli coś refaktorujesz to stanem przejściowym może być coś pomieszanego.

Warto utrzymywać jedną konwencje w projekcie dopóki nie jest to problematyczne.

1 Like