Architettura pulita: accesso a Google / Facebook e livello dati

Question

Architettura pulita: accesso a Google / Facebook e livello dati

#1 da (1 voti)

1

Sto cercando di trovare un modo per integrare l'accesso di Google e Facebook per un'applicazione Android utilizzando l'architettura pulita.

La mia applicazione ha 3 moduli Android Studio:

presentation : contiene il layer Interface Interface di Clean Architecture (Presenters), insieme a tutta la mia UI (Activity, Fragment, Custom Views) (parte del livello Framework e Driver)
dominio : questo è il layer Use Case di Clean Architecture. Contiene i modelli di business, i casi d'uso e le interfacce del repository
dati : contiene tutte le classi Driver e Framework, le librerie (retrofit, database, ecc.) e le implementazioni del repository

Vorrei isolare gli SDK specifici di accesso nel mio livello dati (che è un modulo separato in Android Studio).

Il problema che ho per questo particolare caso d'uso (login di Google per esempio) è che l'SDK deve parlare direttamente al mio livello Attività ( presentazione ). Una volta creato un oggetto specifico, devo chiamare startActivityForResult da un'attività, e ricevo una richiamata nel metodo onActivityResult della mia attività di avvio, contenente le informazioni di accesso.

Queste 2 cose hanno l'obbligo di:

o mantengono le dipendenze dell'SDK di Google / Facebook nel livello della presentazione . MA questo viola il principio dell'architettura pulita, vorrei mantenere queste dipendenze nel mio livello dati
o aggiungi una chiamata che passerà attraverso tutti i miei livelli (presentazione, dominio e dati) per restituire le informazioni di accesso dal metodo onActivityResult . MA Ciò significa che modificherei il mio contratto di dominio a causa di un particolare SDK di accesso

Nessuna di queste sembra OK. Conosci un modo corretto per gestire questo caso d'uso?

clean-code google android login

posta Rafi Panoyan 26.02.2018 - 13:06

fonte

1 risposta

Leggi altre domande sui tag clean-code google android login

Monitoraggio degli errori sulle app che sto vendendo Progetta la soluzione scalabile con la coda

score 1 · Accepted Answer

Se ti capisco bene, stai mappando i tuoi moduli su un'architettura pulita in questo modo:

( Data ( Presentation ( Domain ( ) ) ) )

Va bene. I nomi sono leggermente diversi da quelli che mi aspettavo, ma possono funzionare.

I would like to isolate the login specific SDKs in my data layer (which is a separate module in Android Studio).

Questo è un buon istinto proprio lì. La conoscenza di quale specifico SDK di accesso si sta utilizzando non dovrebbe essere consentito di diffondersi. Conservalo in un unico posto.

The issue I have for this particular use case (Google login for example) is that the SDK need to talk directly to my Activity (presentation layer). Once I have built a specific object, I need to call startActivityForResult from an Activity, and I receive a callback in the onActivityResult method of my launching activity, containing the login informations.

These 2 things make an obligation to :

either keep the Google/Facebook SDK dependencies in the presentation layer. BUT this violates the clean architecture principle, I would like to keep these dependencies in my data layer

L'architettura pulita non è un principio, ma sì, sarebbe male.

or add a call which will go through all my layers (presentation, domain and data) to give back the login informations from the onActivityResult method. BUT this means that I would modify my domain contract because of a particular login SDK

Ricorda che è conoscenza di quale specifico SDK che stiamo utilizzando che vogliamo isolare. L'idea di accedere è sicuramente qualcosa che taglia gli strati. Mentre discendi gli strati, la conoscenza dei dettagli relativi all'accesso dovrebbe essere eliminata. Pertanto, l'SDK di accesso di google può vivere nel tuo livello Data , ma Presentation dovrebbe semplicemente considerarlo come un accesso per presentare in qualche lingua / API di cui parla l'SDK. Questo è il tuo Output Port qui. Domain dovrebbe pensare al login senza preoccuparsi di quale lingua / API parla l'SDK.

Quindi a me sembra ok. Se lo fai bene.