android10 / android10/Android-CleanArchitecture

Where to combine methods from different repositories?

Aperta
#276 3 commenti 1 reazione 0 assegnatari Vedi su GitHub
Lingua principale
Java
Stelle
15.5k
Fork
3.3k
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Descrizione

My question is better asked through an example.

Suppose I have 2 repositories, `UserRepository` and `ChatRepository`, like below.

```
public interface UserRepository
{
/**
* Fetches Accounts of all the users who are friends with the authenticated user.
* @return an Observable that emits all the Accounts of friends in a List.
*/
Observable> allFriendAccounts();
}
```

```
public interface ChatRepository
{
/**
* Fetches the number of messages sent by a peer that are unseen by the authenticated user, by the peer's userId.
* @param peerUserId the userId of the peer.
* @return an Observable that emits the number of unseen messages sent by the peer as a Long.
*/
Observable unseenMessageCount(final String peerUserId);
}
```
The `Account` class is a model inside the domain layer, contains account information associated with a user and exposes them through methods like `getUserId()`, `getUserName()`, `getPhotoUrl()` which are self explanatory.

I also have separate `UseCase`s for those repository methods named `AllFriendAccountsUseCase` and `UnseenMessageCountUseCase`.

Now suppose, I need to show a list of friends in my presentation layer, each item of which shows the name and photo of a friend as well as the number of unseen messages from him/her, similar to the list shown below.

![chat_list](https://user-images.githubusercontent.com/11366464/37916763-844ad7e6-313e-11e8-8578-dbc25492adeb.png)

Obviously I'll need to do at least 2 things.

1. Create a new model class which contains name and photo of a user as well as unseen message count. Possibly create separate model classes for domain and presentation layer.

2. Use both `UserRepository` and `ChatRepository` methods to construct a list, containing objects of the class described in 1. (In short, get the `Account`s of the friends using `allFriendAccounts()`, and then call `unseenMessageCount(final String peerUserId)` for each `Account`, using `Account.getUserId()` as parameter.)

I can think of 2 approaches, each described below.

## Approach 1:

1. Create a model class in domain layer, for example named `ChatItem`, containing user name, photo url and unseen message count.

2. Create a new `UseCase`, for example named `GetChatItems`, which uses both `UserRepository` and `ChatRepository` methods internally to build an `Observable>`.

3. Create a model class in presentation layer, for example named `ChatItemModel`, corresponding to the `ChatItem` in domain layer. Also create the mapper to transform `ChatItem` to `ChatItemModel` and adapter class as needed.

**Problem:** `ChatItem` seems like a presentation detail and seems out of place inside domain model. Should the domain layer know about how its core models are combined and used in presentation layer?

## Approach 2:

1. Do nothing on domain layer.

2. Create a model class in presentation layer, for example named `ChatItemModel`, containing user name, photo url and unseen message count.

3. Use the existing `UseCase`s, `AllFriendAccountsUseCase` and `UnseenMessageCountUseCase` in the presentation layer to build an `Observable>`. Also create the adapter class which uses the emitted list.

**Problem:** Combining `UseCase`s in presentation layer seems ugly.

Looking for suggestions. Is there an approach 3 that I missed completely?

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Direzione di ricerca

Inizia con UserRepository, ChatRepository, AllFriendAccountsUseCase e UnseenMessageCountUseCase, quindi traccia il modo in cui i loro risultati vengono utilizzati dal presentation layer. Confronta i due approcci di layering proposti con la struttura Android Clean Architecture esistente del repository; il lavoro è completato quando viene raggiunta e documentata una raccomandazione architetturale chiara.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
android, java
Ambito
mobile-dev
Tipo di issue
Refactoring
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Ferma
Chiarezza
Da chiarire
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.