Szczegóły implementacyjne

0

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

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

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

Przykładowe implementacje

class MongoTestRepository implements TestRepository {

    private final Mongo mongo;
   
    Mono<User> load(String name) {
        return mongo.findOne(name); //zwraca od razu mono
    }
}
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?

0

Option<User>?

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

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.

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.

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 :)

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.

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.

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

1 użytkowników online, w tym zalogowanych: 0, gości: 1