Ho un servizio wcf che espone un numero piuttosto elevato di metodi di servizio su un singolo indirizzo dell'endpoint. Fino ad ora, tutti i metodi di servizio sono implementati in una singola classe di contratti di servizio. Questa classe di contratti di assistenza implementa diverse interfacce di contratto di servizio. Ora vorrei suddividere l'implementazione dei metodi del contratto di servizio in diverse classi per evitare che la classe del contratto cresca in grande. Io uso uno scenario di auto hosting con un ServiceHost. ServiceHost prende solo il tipo di un singolo tipo che implementa i metodi di servizio, quindi sembra che tutto debba essere implementato in questa classe. Naturalmente la carne dei metodi può essere scomposta in più classi. Ma c'è anche un modo per dividere i metodi in diverse classi?WCF Interfaccia grande su un singolo indirizzo endpoint
risposta
È possibile implementare il servizio come partial class, che consente di dividere l'implementazione su più file.
Se il requisito è mantenere un singolo endpoint e una singola interfaccia, non c'è altro modo di suddividerlo: la classe che si crea deve implementare tutta l'interfaccia.
Vorrei suggerire di mantenere l'implementazione del servizio il più semplice possibile, e solo che ogni metodo sia un one-liner che delega l'operazione all'attuazione effettiva, che può quindi essere suddivisa su più classi. Forse avrebbe anche senso crearne uno per operazione? Questo è uno schema che ho usato prima con successo.
È possibile creare tutti i contratti di servizio desiderati, ciascuno con la propria logica.
Il lato positivo di questo approccio è, come sembra, di raggruppare logicamente funzioni correlate.
Il lato negativo è che il client chiamante deve ora sapere quale servizio utilizzare quando si chiama la funzione.
È un buon approccio per limitare il numero di operazioni nel servizio. Come capisco il tuo scenario, al momento disponi di un'unica implementazione del servizio che implementa diversi contratti di assistenza. Ciò significa che hai già più endpoint sul tuo servizio - ogni enpoint espone un singolo contratto. In quel caso il tuo cliente è già pronto a creare proxy separati per ogni contratto necessario.
Ora si desidera dividere la classe di implementazione del servizio in più implementazioni del servizio. Ogni implementazione del servizio implementerà uno (o più piccolo insieme) di contratti di servizio. Ciò richiederà la modifica della tua applicazione di hosting: sarà necessario ServiceHost separato per ogni implementazione del servizio. Avrai anche bisogno di configurazione separata e indirizzo univoco per ogni implementazione del servizio.
Il lato client può essere ricreato con nuovi servizi, ma penso che dovrebbe anche essere possibile cambiare semplicemente gli indirizzi per gli endpoint e dovrebbe funzionare.
Grazie per la risposta. Attualmente sto pianificando e implementando un'interfaccia di scambio dati per un sistema abbastanza grande. Molto probabilmente i client utilizzeranno sempre l'intera interfaccia e potrebbero essere eseguite su piattaforme diverse. In un szenario penso che sia più facile per il cliente avere un solo indirizzo endpoint. Ho creato diverse interfacce di contratto di servizio e lasciato che una "Interfaccia Master" erediti da tutte le interfacce di contratto di servizio. La classe di contratto servcice implementa quindi l'interfaccia master. – WalterOesch
Grazie per la risposta. Ho anche pensato a classi parziali, ma a mio avviso le classi parziali non aiutano a mantenere una soluzione semplice. Vado come mi hai suggerito, usando una fodera per ogni operazione – WalterOesch