Con per servizi generici:
I servizi generici sono incubi da mantenere. Non puoi facilmente decifrare cosa sta succedendo. E sono difficili da testare poiché ci sono generici. Se il contratto è definito, posso usare uno strumento come SOAP UI per creare facilmente dei messaggi di test. Se generico, devo creare manualmente l'XML (potrei comunque usare l'interfaccia utente SOAP per inviarlo). Che schifo. Strike 1 per manutenibilità e 2 per testabilità.
Tutto con servizi generici entra come una stringa XML. Tutto ciò che non è una stringa deve essere lanciato o convertito nel tipo corretto. Per questo motivo saranno più lenti e consumeranno più risorse. L'analisi XML extra e il richiamo dinamico dei metodi dalle stringhe hanno un sovraccarico maggiore. Sciopero 3 per l'analisi, il cast e la conversione XML inutili e le prestazioni del servizio.
Ho realizzato un modello di dati e un servizio un po 'generici, una volta dove la parte (non tutta) del messaggio erano metadati ed era molto più difficile per le persone capire come i dati andassero e venissero fuori. Era flessibile ma alla fine probabilmente si sarebbe potuto utilizzare un contratto più esplicito poiché non ci sono state troppe aggiunte / modifiche che hanno sfruttato la sua flessibilità sin dall'inizio del servizio.
La pallottola d'argento di non dover mai più cambiare un sistema perché è generica non viene mai realizzata. È un sogno che esiste nella testa dell'architettura astronomica.
I servizi sono meglio serviti con contratti espliciti. Mi mandi X e ti restituirò Y come definito nel contratto. Posso pubblicare il mio contratto per i consumatori in modo che possano codificarlo e persino deriderlo prima del rilascio del servizio.
Il cambiamento accade, quindi la versione dei contratti di servizio. Non è un grosso problema per eseguire alcune versioni differenti del servizio sul tuo server web avendo URL diversi.
Un servizio generico per dominarli è meglio servirlo negli incendi di Mount Doom.