[JacobTheLiar]

hej Mirki od #spring #java, podpowiedzcie mi jak organizować relacje między klasami repozytorium -> serwis -> kontroler.

Pisząc kodzik zauważyłem, że stosuję różne wariacje i się zastanawiam nad tym, które jest bardziej prawilne. Ogólnie staram się stosować zasady SOLID i wychodzi najczęściej opcja 3 ale i stosuję również opcję 2 gdzie chowam metody za interfejsem.

Co o tym sądzicie, jaką metodologię stosujecie, może jeszcze jakąś inną?

[raszidq]

@JacobTheLiar: ja się nie znam, jak klient, ale ma działać :)

[Killeras]

@JacobTheLiar: na tych rysunkach to masz chyba 3 różne sytuacje xD

[JacobTheLiar]

@Killeras: niekoniecznie, w pytanie chodzi o serwis_2, w jaki sposób mam mu udostępniać dane z innych repozytoriów, które są potrzebne do wykonania zadania.

Czy serwis 2 ma bezpośrednio skorzystać z repozytoriów (opcja 1)? Czy może jakiś serwis ma mu udostępnić dane które są mu potrzebne (opcja 2) a może ten serwis rozbić na dwa serwisy idąc drogą pojedynczej odpowiedzialności (opcja 3)?

[Myzreal]

Generalnie to opcja 2, ale opcja 1 też przejdzie jeśli serwis ma mieć dostęp do bardziej niskopoziomowych danych nie "przefiltrowanych" przez ich odpowiedni serwis.

[Kresse]

@JacobTheLiar: Najczesciej robi sie chyba opcje 2, ale ma te wade, ze trzeba czasem forwardowac metody z repo dla innych serwisow tylko po to, zeby zachowac ten schemat. Generalnie serwisy moga szybciej puchnac w takim podejsciu i trudniej je pozniej zrefaktoryzowac np. na 2 serwisy. Latwiej tez o cykliczne zaleznosci. Osobiscie wole opcje 1 z malymi serwisami, ktore skupiaja sie na jednym przypadku biznesowym i ewentualnie "superserwisem" pomiedzy controllerem a

[JacobTheLiar]

@Kresse: Ogólnie z tego co widzę jak wszędzie najważniejszy jest zdrowy rozsądek i można to skwitować osławionym to zależy.

Opcja 3 upraszcza skomplikowane rzeczy rozbijając je na prostsze kawałki.
Opcja 2 wydaje się złotym środkiem dla rozwiązań nie prostych ale i nie skomplikowanych.
Opcję 1 stosować raczej w prostych rozwiązaniach zachowując.