Szczegóły implementacyjne

Szczegóły implementacyjne
F2
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 1
0

Czy interfejs repozytorium powinienen zwracać wartość już opakowaną w np. Mono czy powinno zwrócić czystego usera?

Kopiuj
interface TestRepository {
 
    User load(String name);
}
Kopiuj
interface TestRepository {

    Mono<User> load(String name); // albo CompletableFuture<User> czy cokolwiek w tym stylu
}

Przykładowe implementacje

Kopiuj
class MongoTestRepository implements TestRepository {

    private final Mongo mongo;
   
    Mono<User> load(String name) {
        return mongo.findOne(name); //zwraca od razu mono
    }
}
Kopiuj
class InMemoryTestRepository implements TestRepository {

    private final Map<String, User> users;

    Mono<User> load(String name) {
        return Mono.just(users.get(name));
    }
}

Tylko teraz gdy mam reaktywnego drivera od mongo nie widze sensu żeby te dane odpakować, żeby znowu za chwile je zapakować.
Czyli powinienem nawet implementacje InMemory opakowywać w Mono?

stivens
  • Rejestracja: dni
  • Ostatnio: dni
0

Option<User>?

Charles_Ray
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 1909
4

Różnica jest fundamentalna - przy Mono dostajesz strumień, w którym kiedyś pojawi się element (lub error). Aby to „rozpakować” musiałbyś zablokować wątek, co mija się z celem mając reaktywny driver. Decydując się na reaktywny stack masz w domenie typy reaktywne i musisz z tym żyć - coś za coś.

Czyli powinienem nawet implementacje InMemory opakowywać w Mono?

Tak

W0
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 3755
1
fedis216 napisał(a):

Czy interfejs repozytorium powinienen zwracać wartość już opakowaną w np. Mono czy powinno zwrócić czystego usera?

Musisz się zdecydować na jedno. Czyli albo piszesz reaktywnie, wtedy zwracasz Mono w obu przypadkach. Albo piszesz w blocking, czyli zwracasz User w obu przypadkach. Mieszanie dwóch podejść to bardzo słaby pomysł bo będziesz miał wady obu bez jego zalet - tzn. będziesz miał blokujący kod wraz z Mono, który ma zazwyczaj małą pulę wątków.

Bronzebeard
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 15
0

@Charles_Ray, @wartek01, a co wy na to, żeby reaktywny interfejs zwracał Publisher<User> (https://www.reactive-streams.org/reactive-streams-1.0.3-javadoc/org/reactivestreams/Publisher.html) zamiast konkretnej implementacji jaką jest Mono<User> z Reactor czy Single<T> z ReactiveX? Trzeba trochę więcej gimnastyki, ale w efekcie nie ma sprzęgania na poziomie konkretnej implementacji.

Charles_Ray
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 1909
0

Większa przenośność, ale pewnie mniej dostępnych operatorów. Dla mnie spoko, o ile biblioteki to wspierają, np. możesz zwrócić Publishera ze Spring Data repository :)

jarekr000000
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: U krasnoludów - pod górą
  • Postów: 4712
3

@Bronzebeard:

Jak robisz ogólnodostępną bibliotekę to takie podejście może mieć sens.

W aplikacj/module to jest IMO niepotrzebne przeinżynierowanie, a do tego tracisz informację. I tak zmiana implementacji reactive streams w większym projekcie to raczej SF.

S9
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: Warszawa
  • Postów: 3573
0

W sumie też pytanie po co uzywać reaktywnego programowania? Generalnie jak nie jesteś przysłowowym Netflixem to jest to raczej kiepski pomysł. Kod cięzko do przeczytania i zrozumienia niestety.

KamilAdam
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: Silesia/Marki
  • Postów: 5549
1
scibi92 napisał(a):

Kod cięzko do przeczytania i zrozumienia niestety.

Zależy dla kogo i w jakim języku. W JSie i Haskellu kod reaktywny jest naturalnym rozwiązaniem. Także w Scali dobrze wygląda i dobrze się go czyta

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.