Capisco che i servizi non dovrebbero avere uno stato e nessuna logica aziendale.
- Come puoi implementare un servizio come AuthentificationService considerando queste regole?
- Tutti i metodi in un servizio dovrebbero essere statici?
Diamo un'occhiata alle varie parti della tua domanda.
I understand services should have no state and no business logic.
La tua affermazione (e ipotesi) è solo parzialmente corretta.
Questo è per lo più vero, arrotondato quasi sempre al vero. Il problema è che lo stato di codifica in un servizio diventa un vero dolore. Tenere traccia dello stato; richieste del cliente; timeout; disconnette; risposte lente; bilancio del carico; provisioning del servizio distribuito; sessione di dirottamento; ecc ... tutto si aggiunge a un sacco di spese generali. Quindi è solo più facile non avere stato nel servizio. I problemi elencati principalmente scompaiono e le funzionalità sono più facili da implementare.
Non è vero. In effetti, un servizio è essenzialmente una manifestazione della logica aziendale. Un servizio deve fornire una funzione. Questa funzione rappresenta qualcosa di valore per l'azienda ed è generalmente un elemento della logica aziendale dell'organizzazione.
All the methods in a service should be static?
Penso che ciò dipenda da cosa intendi per static . Se per statico intendi solo una singola istanza del servizio, la risposta è "forse". E penso che questo aspetto sarebbe guidato più dal tuo linguaggio di scelta del servizio che da qualsiasi altra cosa.
Ma se intendi "immutabile", allora la risposta è sì. Un servizio dovrebbe fornire una risposta deterministica a una risposta correttamente formattata. Come genera che la risposta può cambiare, ma la forma e la natura della risposta dovrebbero essere statiche. Un servizio è un'API e una volta rilasciato in natura non dovrebbe cambiare. Se è necessaria una modifica, considera di applicare le versioni ai tuoi servizi.
How can you implement a service like AuthentificationService considering these rules?
Vedi sopra per le incomprensioni nelle ipotesi di base.
Molti framework forniscono questo servizio immediatamente fin quando si collega il framework al proprio provider di autenticazione. L'approccio generale è che le credenziali sono basate sul servizio Authenticate che restituisce un token temporaneo al momento dell'autenticazione corretta. Le altre chiamate basate su client effettuano quindi quella parte token della loro chiamata agli altri servizi. Questi servizi o un livello intermedio verificano che il token sia ancora valido e quindi consentono alla chiamata di servizio di procedere.
potresti rendere l'argomento semantico che il token rappresenta uno "stato" per la sessione client. Ma il token o il tracciamento "stato" è gestito dal cliente e ci sono regole semplicistiche sul lato del servizio per validare e gestire lo "stato". Molti / tutti i problemi associati ai servizi di stato sono ancora evitati.