serwis, menadżer, broker?

cześć,
co oznaczają, albo inaczej - co ludzie nimi oznaczaja - serwis, menadżer, broker
czy jest to po prostu obsługa funkcjonalności?
zakładając np. że obsługujemy w serwisie m.in. bazę filmów i bazę użytkowników,
to serwis (service) użytkowników będzie obsługiwał CRUD użytkowników (zawierając logikę biznesową),
zaś serwis filmów będzie obsługiwał CRUD filmów (z logiką biznesową) ?
czy to jest to samo co menadżer?
co oznacza w takim razie termin broker (trochę rzadziej spotykany chyba)

Końcówki typu Manager, Util, Helper, itd są często objawem kryzysu kreatywności przy wymyślaniu nazwy i segregowaniu funkcjonalności pomiędzy klasami. Używa się ich wtedy, gdy do głowy nie przychodzi nic lepszego.

im więcej członów w nazwie, tym więcej trzeba myśleć przy czytaniu takiego kodu i się zastanawiać czym się różni np. CRUDUserServiceBrokerManagerFactory od
klasy CRUDUserServiceBrokerManager czy CRUDAbstractServiceFactoryodCRUDMovieServiceBrokerManagerFactory`. Za dużo myślenia.

Z drugiej strony łatwo odróżnić klasę User od klasy Movie, i to jest w zasadzie najlepsza opcja, jeśli możesz nazwać klasę jednym słowem (chociaż nie zawsze się da).

zaś serwis filmów będzie obsługiwał CRUD filmów (z logiką biznesową) ?

Ja bym pewnie nazwał taki serwis (tylko, że ja nie piszę w C#, więc mam trochę inne podejście, mniej enterprise) po prostu Movies, no chyba, że miałbym gdzieś indziej w kodzie Movies, które znaczyłoby co innego, wtedy faktycznie mógłbym pomyślałbym o nazywaniu np. MoviesService czy generalnie Movies i jakieś dodatkowe słowo.

Myślę, że to jest klucz, na ile musisz odróżniać jedne klasy od drugich. Jak masz mało klas w projekcie, to łatwiej pomyśleć nad sensowną, krótką nazwą, bo nie będzie ona kolidować z innymi rzeczami.

Chodzi mi o to że movie to encja a operacje (logika biznesowa) operujaca na niej to Service manager lub broker

Jakie mają być te operacje biznesowe? CRUD to raczej nie ma żadnych - od razu z endpointa dane lecą do DAO (bądź vice versa).

Serwis to taka ogólna klasa, która robi coś z czymś albo dla innej klasy. Właściwie każda klasa, która nie jest kontrolerem, prowiderem, repozytorium, encją ani DTO, tudzież nie pełni specjalnej roli w jakimś wzorcu to jest serwis. W wielu aplikacjach można np. wołasz serwis z kontrolera, aby zrealizować jakiś przypadek użycia. Taki serwis też może być odpowiedzialny za prostego cruda. Ale ogólnie takie serwisowe podejście trochę śmierdzi (podejściem z lat osiemdziesiątych).
Są też serwisy domenowe z DDD - tam mają w miarę jasno określony cel, w skrócie realizują logikę, której nie można przypisać do konkretnej encji.

Manager jak sama nazwa wskazuje to klasa, która czymś zarządza - np. jakimiś danymi albo zasobami. W teorii powinna być samodzielna (on bo w końcu kierownik powinien mieć władzę), w praktyce sam za nic nie odpowiada - tylko jest wywoływany z innych klas, więc zazwyczaj to taki szumnie nazywany helper.

Z klasami nazwanymi Util albo Helper nie ma problemu, dopóki grupują pomocnicze metody z jednego zakresu, a nie jeśli jest jeden Helper na cały projekt, który parsuje inty, pisze do logów, deserializuje XML i dzieli stringa na słowa.

Serwis powinien przede wszystkim być bezstanowy nie chodzi o to, żeby nie był oznaczony statikiem tylko żeby historia działań przez niego wykonanych niemiała wpływu na jego zachowanie..

somekind napisał(a):

Manager jak sama nazwa wskazuje to klasa, która czymś zarządza - np. jakimiś danymi albo zasobami. W teorii powinna być samodzielna (on bo w końcu kierownik powinien mieć władzę), w praktyce sam za nic nie odpowiada - tylko jest wywoływany z innych klas, więc zazwyczaj to taki szumnie nazywany helper.

A to ciekawe... :)

somekind napisał(a):

W wielu aplikacjach można np. wołasz serwis z kontrolera, aby zrealizować jakiś przypadek użycia. Taki serwis też może być odpowiedzialny za prostego cruda. Ale ogólnie takie serwisowe podejście trochę śmierdzi (podejściem z lat osiemdziesiątych).

Możesz napisać coś więcej na temat tego dlaczego Twoim zdaniem takie podejście "śmierdzi latami osiemdziesiątymi", tzn chodzi mo o to w kontekśie wad takiego podejścia ? W moich dotychczasowych projektach (stosunkowo mało złożonych) takie podejście było dośc często używane (razem z Dependency Injection, unit testami itd) i w zasadzie sprawdzalo się dobrze.

W2K napisał(a):

somekind napisał(a):

W wielu aplikacjach można np. wołasz serwis z kontrolera, aby zrealizować jakiś przypadek użycia. Taki serwis też może być odpowiedzialny za prostego cruda. Ale ogólnie takie serwisowe podejście trochę śmierdzi (podejściem z lat osiemdziesiątych).

Możesz napisać coś więcej na temat tego dlaczego Twoim zdaniem takie podejście "śmierdzi latami osiemdziesiątymi", tzn chodzi mo o to w kontekśie wad takiego podejścia ? W moich dotychczasowych projektach (stosunkowo mało złożonych) takie podejście było dośc często używane (razem z Dependency Injection, unit testami itd) i w zasadzie sprawdzalo się dobrze.

Chodzi o to, że projekt zpychasz w stronę programowania proceduralnego. No a żeby kod ładnie pachniał to musisz programować obiektowo najlepiej żebyś miał CQRS i jeszcze z ES bo tak się programuje dzisiejszych latach. :)

No a żeby kod ładnie pachniał to musisz programować obiektowo najlepiej
żebyś miał CQRS i jeszcze z ES bo tak się programuje dzisiejszych latach

Nie jestem pewien czy piszesz ironicznie, czy naprawdę w to wierzysz o.O

W2K napisał(a):

Możesz napisać coś więcej na temat tego dlaczego Twoim zdaniem takie podejście "śmierdzi latami osiemdziesiątymi", tzn chodzi mo o to w kontekśie wad takiego podejścia ? W moich dotychczasowych projektach (stosunkowo mało złożonych) takie podejście było dośc często używane (razem z Dependency Injection, unit testami itd) i w zasadzie sprawdzalo się dobrze.

Inne podejścia nie wykluczają przecież DI ani testów.
Też stosowałem i stosuję to podejście, tylko taki serwis zawierający np. wszystkie metody do cruda + jeszcze do jakichś innych operacji staje się takim god-objectem łamiącym SRP. Tym gorzej, jeśli nie ma przełożenia 1 kontroler : 1 serwis, tylko jeden serwis obsługuje wiele kontrolerów.
Poza tym, że sam taki serwis jest brzydki, to testy są jeszcze gorsze - bo ludzie na ogół piszą testy do wszystkich metod jednej klasy w jednej klasie testującej. Przy paru przypadkach brzegowych i możliwych wyjątkach łatwo tu osiągnąć np. 2k linii.
No i dependency injection też jest niezbyt ładne - kontener trzyma konfigurację dla bardzo wielu klas, każdy kontroler ma inne zależności, itd.

Można chyba prościej - obiekty requestów wysyłane z kontrolera przez szynę, każdy kontroler ma tę samą zależność od szyny, szyna znajduje handler to request, a każdy request ma jednego handlera z jedną publiczną metodą.

Czyli w sumie to co napisałeś najblizej opisuje wzorzec mediatora. Chyba muszę w e temu bliżej przyjrzeć bo w sumie problemy o których piszesz też mi się po drodze pojawiły. Jedyne co mi się potencjalnie nie podoba to to że tak mediator wymaga sporej liczby obiektów pomocniczych które używane są do przekazywania tych requestow

somekind napisał(a):

W2K napisał(a):

Możesz napisać coś więcej na temat tego dlaczego Twoim zdaniem takie podejście "śmierdzi latami osiemdziesiątymi", tzn chodzi mo o to w kontekśie wad takiego podejścia ? W moich dotychczasowych projektach (stosunkowo mało złożonych) takie podejście było dośc często używane (razem z Dependency Injection, unit testami itd) i w zasadzie sprawdzalo się dobrze.

Inne podejścia nie wykluczają przecież DI ani testów.
Też stosowałem i stosuję to podejście, tylko taki serwis zawierający np. wszystkie metody do cruda + jeszcze do jakichś innych operacji staje się takim god-objectem łamiącym SRP. Tym gorzej, jeśli nie ma przełożenia 1 kontroler : 1 serwis, tylko jeden serwis obsługuje wiele kontrolerów.
Poza tym, że sam taki serwis jest brzydki, to testy są jeszcze gorsze - bo ludzie na ogół piszą testy do wszystkich metod jednej klasy w jednej klasie testującej. Przy paru przypadkach brzegowych i możliwych wyjątkach łatwo tu osiągnąć np. 2k linii.
No i dependency injection też jest niezbyt ładne - kontener trzyma konfigurację dla bardzo wielu klas, każdy kontroler ma inne zależności, itd.

Można chyba prościej - obiekty requestów wysyłane z kontrolera przez szynę, każdy kontroler ma tę samą zależność od szyny, szyna znajduje handler to request, a każdy request ma jednego handlera z jedną publiczną metodą.

W większości przypadków jest to leczenie syfa pudrem. Jeśli nie potrafi się projektować klasy pojęciowo to się je projektuje pod request. Jedyne co ci prawdopodobnie jest potrzebne to statyczny Śervis z komendami.

Jeśli nie umiesz z konfigurować kontenera albo używasz słabego to będzie on brzydko wyglądał. To samo ma się do pisania testów pod klasę zamiast jednostkę.

W2K napisał(a):

Czyli w sumie to co napisałeś najblizej opisuje wzorzec mediatora.

No, powiedzmy, że tak.

Jedyne co mi się potencjalnie nie podoba to to że tak mediator wymaga sporej liczby obiektów pomocniczych które używane są do przekazywania tych requestow

Jakich konkretnie obiektów? Request, który przyjmuje akcja kontrolera może być przecież przesłany dalej.

Smutny Kret napisał(a):

W większości przypadków jest to leczenie syfa pudrem. Jeśli nie potrafi się projektować klasy pojęciowo to się je projektuje pod request.

Tylko my tu właśnie mówimy tu o przypadku, w którym istnieją duże serwisy posiadające multum metod, a nie "projektowane pod request".

Jedyne co ci prawdopodobnie jest potrzebne to statyczny Śervis z komendami.

Statyczny serwis z komendami do czego? Jak to rozwiązuje problem przerośniętych serwisów?

Jeśli nie umiesz z konfigurować kontenera albo używasz słabego to będzie on brzydko wyglądał.

Po pierwsze to to, że można do kontrolera wsadzić milion klas, nie znaczy, że to jest fajne.
Po drugie nie chce mi się pamiętać, w którym serwisie jest co, żeby dodać go jako kolejny parametr konstruktora kontrolera. Wystarczy jedna "uniwersalna" zależność.

To samo ma się do pisania testów pod klasę zamiast jednostkę.

Owszem, tylko większość osób jednak testuje klasy.

somekind napisał(a):

W2K napisał(a):

Po pierwsze to to, że można do kontrolera wsadzić milion klas, nie znaczy, że to jest fajne.
Po drugie nie chce mi się pamiętać, w którym serwisie jest co, żeby dodać go jako kolejny parametr konstruktora kontrolera. Wystarczy jedna "uniwersalna" zależność.

Czyli masz abstrakcyjną fabrykę, która produkuje ci handlery no i co w tym takiego fajnego? Przecież będziesz musiał mieć tą szyna w każdej metodzie, jaka kolwiek zmiana w tej szynie będzie miała wpływ na całą aplikację. Uniwersalna zależność, to raczej nie brzmi dobrze....

Smutny Kret napisał(a):

Przecież będziesz musiał mieć tą szyna w każdej metodzie, jaka kolwiek zmiana w tej szynie będzie miała wpływ na całą aplikację. Uniwersalna zależność, to raczej nie brzmi dobrze....

No i to jest właśnie argument za zmiana. Bo przy podejściu "serwisowym" niektóre zależności i tak są we wszystkich (albo prawie) kontrolerach, jakakolwiek zmiana takiej szeroko używanej zależności ma wpływ na całą aplikację. A szyna po prostu przyjmuje request i przesyła go do odpowiedniego handlera, w samej szynie się nie ma co zmienić.

Poza tym nie rozumiem czemu pięć zależności w metodzie jest dobre, a jedynie jedna jest zła?

Można użyć tutaj pewnej analogii architektury zorientowanej na wiadomości - microserwisy komunikujące się za pomocą np. : RabbitMQ, Apache Kafka.
Cyt : "The simplest form of a message broker is a system that routes messages between services."
The services — the dancers
The message broker — the music
The messages — the notes
The topics or channels — the sound system