WCF: oggetti di dominio e IExtensibleDataObject

Question

Scenario tipico.Utilizziamo servizi Web XML della vecchia scuola internally per la comunicazione tra una server farm e diverse distribuite E clienti locali.Nessuna terza parte coinvolta, solo le nostre applicazioni utilizzate da noi stessi e dai nostri clienti.

Attualmente stiamo riflettendo sul passaggio da XML WS ad a WCF/object-based modello e hanno sperimentato vari approcci.Uno di questi prevede il trasferimento degli oggetti/aggregati del dominio direttamente in rete, eventualmente invocando su di essi gli attributi DataContract.

Usando IExtensibleDataObject e un DataContract utilizzando la proprietà Order su DataMembers, dovremmo essere in grado di far fronte a semplici problemi di controllo delle versioni delle proprietà (ricorda, controlliamo tutti i client e possiamo facilmente forzarne l'aggiornamento).

Continuo a sentire che dovremmo utilizzare oggetti di trasferimento dati dedicati e di solo trasferimento (DTOs) sul filo.

Perché?C’è ancora un motivo per farlo?Usiamo lo stesso modello di dominio lato server e lato client, ovviamente, precompilando raccolte, ecc.Solo quando considerato giusto e "necessario". Proprietà di raccolta Utilizzare il principio del localizzatore di servizio e IOC per invocare un NHibernate-based "servizio" per recuperare i dati direttamente (sul lato server) e a WCF client "servizio" sul lato client per parlare con WCF fattoria di server.

Allora, perché dobbiamo usarlo DTOs?

Answer 1

Nella mia esperienza i DTO sono più utili per:

1. Definire rigorosamente ciò che verrà inviato via cavo e avere un tipo specificamente dedicato a tale definizione.
2. Isolando il resto della tua applicazione, client e server, da modifiche future.
3. Interoperabilità con sistemi non .Net.I DTO non sono certamente un requisito, ma rendono più semplice la progettazione di tipi "sicuri".

Nel tuo scenario queste funzionalità di progettazione potrebbero non avere molta importanza.Ho utilizzato WCF sia con DTO rigorosi che con oggetti di dominio condivisi e in entrambi gli scenari ha funzionato benissimo.L'unica cosa che ho notato durante l'invio di oggetti di dominio via cavo è stata che tendevo a inviare più dati (e in modi inaspettati) di quelli necessari.Ciò è probabilmente dovuto più alla mia mancanza di esperienza con WCF che a qualsiasi altra cosa;ma è qualcosa di cui dovresti assolutamente diffidare se scegli di seguire questa strada.

Answer 2

Avendo lavorato con entrambi gli approcci (oggetti di dominio condiviso e DTO), direi che il grosso problema con gli oggetti di dominio condiviso è quando non controlli tutti i client, ma dalle mie esperienze passate di solito utilizzerei i DTO a meno che la velocità di sviluppo non fosse di l'essenza.

Se c'è qualche possibilità che non avrai sempre il controllo dei client, allora consiglierei sicuramente i DTO, perché non appena condividi gli oggetti del tuo dominio con l'applicazione client di qualcun altro inizi a legare i tuoi interni al ciclo di sviluppo di qualcun altro.

Ho trovato utili i DTO anche quando si lavora in un ambiente di servizio con versione, che ci ha permesso di modificare radicalmente gli interni della nostra app ma di accettare comunque chiamate alle vecchie versioni delle nostre interfacce di servizio.

Infine, se disponi di molte applicazioni client, potrebbe anche essere utile utilizzare i DTO poiché sarai protetto con un servizio facilmente modificabile.