Modelli per compensare la mancanza di ereditarietà in SOA

Trovo l’ereditarietà e il concetto di class base come il punto più forte di OOP. Ma questo non è incoraggiato in SOA. Quindi, quali sono i modelli popolari per superare questa limitazione in SOA? Potresti fornire tutorial che spieghino (con la dimostrazione del codice in WCF) questi pattern?

Nota: questa NON è una domanda generale sui pattern disponibili in SOA. Ma è più specifico del problema sopra citato.

Nota: sto usando WCF per SOA.


Lettura:

  1. “Non utilizzare la class Abstract Base in Design; ma in modellazione / analisi ”

  2. In che modo un’architettura SOA dovrebbe essere implementata?

  3. Come affrontare il polimorfismo Java nell’architettura orientata ai servizi

  4. Come arrivare alla velocità su SOA?

  5. Cos’è l’architettura orientata ai servizi?

  6. DDD e SOA funzionano davvero bene insieme?

  7. Domande di progettazione SOA e WCF: si tratta di un design di sistema insolito?

  8. Progettare i contratti e le operazioni relativi ai dati WCF

  9. Expando Objects in C # 4.0

Indipendentemente dal fatto che pensiate a SOA come implementato da SOAP, REST o messaggistica, i servizi sono incentrati sui documenti. I servizi non sono orientati agli oggetti .

Sebbene il polimorfismo sia un forte strumento di progettazione in OOD, non è applicabile in SOA perché la modellazione SOA non prevede classi.

Trovo l’ereditarietà e il concetto di class base come il punto più forte di OOP.

Non sopravvalutare il potere dell’ereditarietà – quasi tutti i modelli GoF riguardano l’evitare l’uso errato dell’ereditarietà.

Ma questo non è incoraggiato in SOA.

No, generalmente non è incoraggiato. Perché? Perché in SOA hai un servizio che fornisce alcune operazioni. Il servizio stesso è definito dalla descrizione del servizio (contratto / interfaccia). In caso di contratto di servizi SOAP è descritto in WSDL. Se è necessario disporre di un altro servizio che fornisca lo stesso insieme di operazioni con un comportamento leggermente diverso, sarà necessario implementare nuovamente l’interfaccia e indirizzare il client a un nuovo servizio (fornendo un nuovo URL endpoint). Quindi l’ereditarietà con il contratto di assistenza “funziona” ma non funziona allo stesso modo con i contratti di dati.

Ogni operazione di servizio di solito accetta alcuni dati e restituisce alcuni dati. Questi dati sono nuovamente descritti nella descrizione del servizio. Nel caso di servizi SOAP i dati sono descritti come XSD. Quando si inviano dati da client a servizio (o in direzione inversa) i dati devono essere serializzati e la destinazione deve poterli deserializzare (a meno che non si desideri lavorare direttamente con buste SOAP o se non si desidera utilizzare xsd: any = XML non codificato come passato dati). Se si desidera utilizzare l’ereditarietà nel contratto di dati, è necessario in qualche modo includere informazioni sui contratti derivati ​​nella descrizione del servizio. Solo dopo aver incluso queste informazioni nella descrizione del servizio è ansible informare gli utenti del servizio dell’esistenza di contratti di dati ereditati (hanno bisogno di queste informazioni per lavorare con i tipi derivati).

WCF offre la possibilità di lavorare con contratti dati ereditati. È ansible utilizzare l’attributo KnownTypeAttribute , ServiceKnownTypeAttribute o DataContractResolver . Puoi anche controllare questo fantastico articolo per maggiori dettagli.

In caso di sistemi non interoperabili e strettamente accoppiati (non SOA) è ansible utilizzare NetDataContractSerializer che consente di utilizzare l’ereditarietà senza limitazioni poiché ogni messaggio serializzato contiene informazioni sul tipo CLR necessario per la deserializzazione ei client con il servizio devono condividere gli assembly del contratto dati.

Una ragione per cui l’ereditarietà non è raccomandabile in SOA è perché il tuo codice è centrato sul modello. Avete modelli di entrata e uscita ben definiti e il vostro codice dovrebbe tradursi tra i due, oltre a eseguire qualsiasi logica di business.

Avere ereditari significherebbe solo che le relazioni tra i tuoi oggetti sono difficili da modellare e / o cambiare nel tempo. Fondamentalmente questo significa usare gli oggetti del modello POCO.

Se vuoi aggiungere la logica di business al tuo cound, usa i mixin per imitare l’ereditarietà.