Design pattern quando tutto l'accesso ai dati avviene attraverso un servizio web [chiuso]

I want to stay away from that approach to limit the main project's access to the web service by creating a class for each entity on the data layer that which inherits the corresponding entity from the web service.

Non lo farei, e non puoi comunque-- se una classe di una libreria eredita da un'altra classe in quella libreria, entrambe le classi devono essere pubbliche .

Invece, lo farei in questo modo

1. Dimentica il servizio Web esistente.
2. Definisci un modello di dominio che il chiamante del tuo servizio troverà più adatto al problema in questione.
3. Scrivi il codice per eseguire il mapping tra le classi del servizio Web e il modello di dominio.

Si noti che potrebbe non esserci una mappatura 1: 1; ad esempio, il chiamante della tua libreria potrebbe voler lavorare con una sola classe User mentre sotto le copertine esegue il mapping a una classe UserDetails e UserPermissions esposta dal servizio web. Oppure il contrario potrebbe essere vero, ad es. il servizio espone una gigantesca classe Everything e il modello di dominio espone quello in due o più classi che hanno senso per il chiamante con cui lavorare.

A proposito, questo genere di cose è comune-- non pensare che stai facendo qualcosa di "sbagliato" scrivendo due strati di classi. Il compito della biblioteca è quello di consolidare e semplificare la complessità di fondo del servizio web; questa è una buona cosa.

Vorrei creare un modello comune che puoi usare sia sul tuo client che sul tuo server. È possibile distribuire questi modelli in un pacchetto separato in modo che il client non dipenda direttamente dal codice del servizio.

client -> models
service -> models

Se si duplicano le classi nel client definite nel servizio, è probabile che ci siano errori dalle differenze nel modello e sarà più difficile mantenere entrambi i modelli.