Consente di tornare alle origini:
Service: work done for somebody else: work done by somebody for somebody else as a job, duty, punishment, or favor.
Come suggerisce la definizione, c'è un punto qualsiasi nella tua applicazione in cui hai bisogno del codice per eseguire il lavoro per qualsiasi altro pezzo di codice?
"Ovunque" si potrebbe dire, questo è ciò che fanno le classi! ... e ad un livello fondamentale avresti ragione. C'è un parallelo interessante che viene fatto in Programmazione dei servizi WCF tra la struttura del codice ordinario (con metadati, un'interfaccia e un'implementazione) e servizi web che hanno anche queste proprietà. Quindi, in sostanza, tutto il codice può essere classificato come un servizio. Penso che sia una visione interessante e preziosa di questa classe di problemi.
Se una classe è realmente, funzionalmente equivalente a un servizio ... quali domande ti chiedi quando decidi di creare una nuova classe? Tieni a mente i principi SOLID qui.
Suppongo che tu (o dovresti) porsi queste stesse domande quando decidi se creare o meno un servizio web, ma solo a un livello più alto di astrazione.
Per una classe, alcune di queste domande sarebbero *:
- Esiste un insieme di funzioni comuni che il resto del mio codice deve consumare?
- c'è un insieme di dati comuni di cui il resto del mio codice dovrà conoscere / avere accesso?
- Sto codificando più volte la stessa struttura nei miei progetti?
- Sto codificando più volte la stessa cosa / modello nei miei progetti?
Porta questo tipo di domande a un livello più alto di astrazione o a un set di codice logicamente più ampio e se rispondi "sì", allora hai un candidato per un servizio web.
* non un elenco esaustivo