Perché WCF è stato progettato per violare il Principio di sostituzione di Liskov?

Question

Perché WCF è stato progettato per violare il Principio di sostituzione di Liskov?

#1 da (4 voti)

1

Quando vuoi inviare i tuoi tipi su WCF, devi aggiungere un sacco di [ServiceKnownType(typeof(MyFirstConcreteType))] alla definizione dell'interfaccia del tuo contratto. Non è possibile utilizzare [ServiceKnownType(typeof(IMyInterface))] , anche se questo verrà compilato e quindi fallito in fase di runtime.

Anche quando definisci MyExtendedFirstConcreteType : MyFirstConcreteType , devi aggiungere un extra [ServiceKnownType(typeof(MyExtendedFirstConcreteType))] .

Questa è una chiara violazione del Principio di sostituzione di Liskov, perché non è possibile utilizzare un tipo derivato in cui è possibile utilizzare il tipo di base.

Perché WCF è stato progettato con questo difetto? Sono disponibili soluzioni efficaci?

Sebbene tali domande siano irrilevanti per le scimmie di codice, un architetto di software dovrebbe comprendere le tecnologie che sceglie, conoscere i loro vantaggi e svantaggi e applicare tale conoscenza al progetto. Un caposquadra potrebbe utilizzare questo input dall'architetto per scoprire se ci sono abbastanza membri del team con una sufficiente conoscenza di tali tecnologie e forse stimare i costi di formazione e introduzione rispetto a una tecnologia con cui il team è esperto. nel reparto Qualità potrebbe essere sconvolto sentire che potrebbe apparire un errore di runtime che difficilmente può essere prevenuto con metodi di test automatici: l'architetto potrebbe aver bisogno di una buona ragione per accettarlo. Ecc.

liskov-substitution wcf

posta Bernhard Hiller 13.07.2018 - 16:13

fonte

1 risposta

Leggi altre domande sui tag liskov-substitution wcf

Vantaggio dell'utilizzo della chiave di emissione JIRA nel flusso di lavoro basato su fork Come approccio alla strutturazione quando leggere / scrivere oggetti in db?

score 4 · Answer 1

La mia comprensione è che si tratta di un problema di deserializzazione dell'XML alle effettive classi concrete.

Il client WCF deve istanziare la stessa classe, o almeno una classe con le stesse proprietà pubbliche, della classe che è stata inviata dal server.

Questo pone un problema quando viene utilizzata una classe derivata al posto della classe o dell'interfaccia specificata come metodo di ritorno del metodo.

L'utilizzo degli attributi KnownType e ServiceKnownType fa sì che i KnowTypes siano inclusi nel WSDL e abiliti la deserializzazione degli oggetti restituiti al tipo corretto.

Why not send the class information when the new class is sent?

Una delle cose fondamentali con WCF è la possibilità di pubblicare tutte le informazioni necessarie per consumare il servizio. Ciò consente a un client di generare autonomamente dal WSDL con la propria versione delle classi. Considerato un aspetto importante dell'architettura, sebbene spesso evitato con le opzioni 'usa classi conosciute localmente'

Ma ciò richiede che tutte le possibili classi siano conosciute in anticipo. Se si inviava dinamicamente una nuova classe non inclusa nel WDSL, il client sarebbe costretto a rappresentare la classe base come dinamica o come tale e non sapere quali Proprietà potrebbero essere incluse in fase di runtime.

Why not analyse the code base to determine all possible subtypes rather than use attributes

Tralasciando le complicazioni causate dal caricamento dei tipi in fase di esecuzione, ciò dovrebbe essere possibile. Tuttavia, WCF fa ampio uso di attributi, così come altre tecnologie MS del tempo. Fa davvero la differenza per LSP se un attributo deve essere aggiunto a mano o se viene aggiunto automaticamente da una fase di precompilazione?