Architettura pulita: app che fanno molto affidamento sui servizi in background

1

Sto cercando di implementare un'architettura pulita ( link ) su un'app Android. Ad esempio, supponiamo che tutta l'app esegua il monitoraggio della temperatura della CPU di un utente e visualizzi una media oraria e giornaliera. I dati sono memorizzati sul dispositivo e periodicamente sottoposti a downsampling. I dati sottocampionati vengono caricati su un back-end.

Tutti gli esempi di architettura pulita che ho visto riguardano gli stessi tipi di app, ad es. App che hanno una UI in CRUD, di solito qualcosa nella riga: L'interfaccia utente invia eventi di clic al presentatore, il presenter esegue un caso d'uso, l'interprete recupera i dati da un repository, il presentatore invia i dati all'interfaccia.

La mia app ha praticamente zero interazione con l'utente:

  • Un servizio in background misura la temperatura della CPU e la scrive nel
    banca dati.
  • Un processo in background separato esegue il downsampling dei dati e lo scrive al database.
  • Ancora un altro processo in background sincronizza i dati downsampled con il backend
  • I servizi in background sono programmati per essere eseguiti su un intervallo fisso da un job scheduler
  • Tutto ciò che l'utente vede è la sua CPU attuale, le medie e forse notifiche che la sincronizzazione è stata completata con successo.

Come lo strutturerei in termini di architettura pulita? Più in particolare:

  • Quali sono i miei casi d'uso?
  • I servizi nello stesso livello della vista sarebbero stati?
  • Ho bisogno di un presentatore? (Forse per visualizzare notifiche di stato dal servizio, non riesco a vedere nessun altro motivo?)
  • Ho bisogno di repository separati per i miei dati ad alta risoluzione e bassa risoluzione?

Mi rendo conto che ci sono molte domande, ma apprezzerei qualsiasi input o suggerimento nella giusta direzione.

    
posta HPage 23.02.2018 - 09:30
fonte

2 risposte

2

La parte importante di Clean Architecture (CA) non sono i presentatori e i controller. Il punto importante della CA è che esiste un "nucleo" della tua applicazione, che rappresenta i tuoi casi aziendali. E che tutta l'interfaccia utente, l'infrastruttura, il servizio oi database dipendono da questo core e non viceversa. Raccomando wowing discorso dello zio Bob per ottenere un'immagine più chiara.

Quando guardo il tuo codice, il tuo caso d'uso "principale" è una pipeline. Questa pipeline è composta da più parti, ciascuna gestita separatamente con un database tra di esse. Ma insieme, fanno un po 'di elaborazione. Quello che mi piacerebbe vedere è un test automatico che verifica l'intera pipeline come unità singola. Il database e lo scheduler verrebbero presi in giro e la pipeline non saprebbe se è in esecuzione in produzione o se è in fase di test con database in memoria e viene eseguito direttamente e non tramite lo scheduler.

    
risposta data 23.02.2018 - 12:40
fonte
0

Il paradigma MVC è una linea guida per strutturare il tuo programma in modo corretto e facilmente interpretabile. Come dici tu stesso, c'è pochissima interazione e vista con l'utente, quindi dovresti creare classi e livelli che alla fine eseguono uno scopo banale? Potresti, naturalmente, ma non è più corretto e facilmente interpretabile. I programmatori che leggono il tuo progetto sarebbero sbalorditi dall'esistenza di classi di vista che fanno poco più che prendere la media, arrotondarla a 2 cifre decimali e mostrarla sullo schermo. È utile ricordare che è solo una linea guida, non un regolamento di codifica.

Per rispondere alle tue domande specifiche:

What are my use cases?

Ecco qua:

L'utente desidera conoscere l'utilizzo medio della CPU. L'utente inserisce il programma e nota chiaramente la percentuale indicata. L'utente chiude il programma.

L'utente desidera conoscere l'ultimo programma orario sincronizzato. L'utente inserisce il programma e prende nota chiaramente della data. L'utente chiude il programma.

È semplice come probabilmente hai già indovinato. Non analizzare troppo.

Are the services in the same layer as the view would have been?

Onestamente, vorrei separare le attività in background con l'interfaccia utente utente, ma soprattutto perché le attività eseguite sono chiaramente diverse. Quindi no.

Do I need a presenter at all? (Maybe for displaying status notifications from the service, I can't see any other reason?)

Potrei vedere forse la necessità di una classe focalizzata esclusivamente sulla canalizzazione dei dati in dati che l'utente può vedere. Penso che chiamarlo un presentatore stia glorificando un po 'il ruolo.

Do I need separate repositories for my high resolution and lower resolution data?

Non lo farei. Se puoi prendere in considerazione un secondo tavolo.

    
risposta data 23.02.2018 - 11:48
fonte

Leggi altre domande sui tag