Clean Architecture Archives

Do Clean Architecture można podejść na kilka sposobów. Jednym z rozwiązań jest zastosowanie RxJavy 2 i w tym poście przyjrzymy się bliżej tej opcji. W warstwie prezentacji użyjemy sprawdzonego wzorca Model View Presenter, w warstwie domenowej będziemy mieć UseCase’y z pojedynczą odpowiedzialnością, natomiast w warstwie danych Repository Pattern. Wszystko to będzie sterowane streamami z RxJavy. Repository Pattern Przypuśćmy, że mamy presenter, który pobiera nam użytkowników i ustawia ich dane wywołując odpowiednie metody na widoku. Presenter nie powinien wiedzieć, skąd są dane, dlatego początkowo stwórzmy UsersRepository, które będzie korzystać z bazy danych oraz serwisu REST. W poniższych przykładach użyty został także Dagger2. Nie jest on niezbędny, jednak znacznie ułatwia implementację. @Singleton public class UsersRepository { public static final int DEFAULT_AMOUNT = 5; private UsersService usersService; private DatabaseManager databaseManager; @Inject public UsersRepository(UsersService usersService, DatabaseManager databaseManager) { this.usersService = usersService; this.databaseManager = databaseManager; } public Flowable loadUsers(String gender) { Flowable remoteUsers = usersService.getUsersList(DEFAULT_AMOUNT).flatMap(Flowable::fromIterable); Flowable localUsers = databaseManager.getUsers(); return remoteUsers.concatWith(localUsers).filter(user -> user.getGender().equals(gender)); } } Załóżmy tutaj uproszczoną logikę, jakoby ładowanie użytkowników z repozytorium dostarczało elementy pobrane z serwera, jak i z bazy danych. Możemy to zrobić przez skonkatenowanie 2 streamów pochodzących z UsersService i DatabaseManager, obiektów wstrzykiwanych za pomocą Daggera do repozytorium. Oba zwracają dane za pomocą Flowable, jednak serwis dostarcza nam Flowable, zaś baza danych Flowable. Dzięki operatorowi fromIterable przerabiamy stream listy na stream elementów i konkatenujemy oba streamy poprzez concatWith. Dodatkowo metoda loadUsers przyjmuje w argumencie płeć, po jakiej ma filtrować użytkowników. Use Case Mamy już gotowe repozytorium, ale presenter nie powinien korzystać z niego bezpośrednio. Do presenterów wstrzykujemy przede wszystkim UseCase’y, które to mogą korzystać z wielu repozytoriów. UseCase’y definiują nam wszystkie akcje, jakie można wykonywać w aplikacji, a każdy z nich ma pojedynczą odpowiedzialność. Stwórzmy sobie więc GetUsersUseCase, który pobiera użytkowników z repozytorium. Nazewnictwo zależy oczywiście od konwencji, ja wybrałem poniższą. public class GetUsersUseCase extends SingleUseCase { private UsersRepository userRepository; private String gender; @Inject public GetUsersUseCase(UsersRepository userRepository) { this.userRepository = userRepository; } public void setGender(String gender) { this.gender = gender; } @Override protected Single buildUseCaseSingle() { return userRepository.loadUsers(gender).toList(); } } Jak widać, możemy tu wyszczególnić metodę buildUseCaseSingle(), którą nadpisujemy z klasy nadrzędnej – SingleUseCase. To co tam się znajduje omówimy za chwilę, natomiast na razie najważniejsze jest to, aby wewnątrz metody buildUseCaseSingle() zwrócić stream, który będzie interesował presentera. W tym przypadku jest to Single zawierający listę użytkowników. Jeśli chcemy wywołać metodę z repository z wybranymi parametrami po prostu tworzymy dodatkowe pole i setter. Single Use Case public abstract class SingleUseCase extends UseCase { protected abstract Single buildUseCaseSingle(); private Single buildUseCaseSingleOnIo() { return buildUseCaseSingle().compose(RxUtil.applySingleIoSchedulers()); } public void execute(final Consumer

Reaktywne podejście do Clean Architecture

Wycena projektu

Dlaczego warto rozwijać z nami projekty?

Reaktywne podejście do Clean Architecture

Udostępnij

Wycena projektu

Dlaczego warto rozwijać z nami projekty?