Struttura dell'applicazione utilizzando WCF

Question

Ho un'applicazione WPF che finora è stata solo client, ma ora sto lavorando per suddividerla in un lato client e server. In questo lavoro sto introducendo WCF per la comunicazione client-server. La mia applicazione ha diversi progetti e sono necessari riferimenti di servizio da più di uno di questi.

Lo sforzo iniziale nel fare la separazione è fare tutto "in modo diretto". Tutti i progetti che devono comunicare con un servizio ricevono un riferimento al servizio, e così anche il progetto principale dell'applicazione WPF - per ottenere l'app.config lì. Trovo che questo si trasformi in un casino piuttosto rapidamente, e non riesco a immaginare che questa sia la tipica architettura usata dalle persone? Ho anche riscontrato problemi con il fatto che ognuno dei riferimenti al servizio genera una nuova implementazione delle classi DataContract - quindi non esiste una comprensione comune delle classi DataContract su più progetti. Ho alcune classi ViewModel in un progetto e un altro progetto che installa alcuni ViewModel. Mi piacerebbe passare l'oggetto ricevuto dal servizio, ma non posso come la rappresentazione generata lato client dell'oggetto ricevuto differisce in ogni progetto.

Quindi, c'è un modo consigliato di strutturare tali separazioni client/server utilizzando WCF? O principi da seguire? Sto pensando a un progetto Proxy comune utilizzato sul lato client che esegue la comunicazione con i servizi, avvolge i dati ricevuti e restituisce i dati su un modulo ben noto alle librerie client. Dovrebbe dare solo un riferimento al servizio, e credo che mi occorresse solo App.config nel progetto wpfApp? Ha senso ciò?

Answer 1

mi piace di strutturare le mie soluzioni WCF come questo:

Contratti (libreria di classi)
contiene tutti i contratti di servizio, le operazioni, di guasto e di dati.Possono essere condivisi tra server e client in uno scenario puro NET-to-NET

implementazione Servizio (libreria di classi)
contiene il codice per implementare i servizi, e di tutti i metodi di supporto/helper necessario per raggiungere questo obiettivo . Nient'altro.

host del servizio (s) (opzionale - può essere WinForms, console di App, servizio NT)
Contiene host del servizio (s) per il debug/test, o, eventualmente, anche per la produzione.

Questo fondamentalmente mi dà il lato server delle cose.

Sul lato client:

proxy client (libreria di classi)
mi piace il mio pacchetto di proxy client in una libreria di classe separata, in modo che possano essere riutilizzati da più applicazioni client effettivi. Questo può essere fatto usando svcutil o "Aggiungi riferimento al servizio" e modificando manualmente l'orribile app.config risultante, oppure eseguendo manualmente i proxy client (quando si condivide l'assembly dei contratti) usando i costrutti ClientBase<T> o ChannelFactory<T>.

1-n clienti attuali (qualsiasi tipo di applicazione)
in genere solo come riferimento il gruppo proxy client, o forse l'assemblea contratti, anche se quest'ultimo è stato condiviso. Può trattarsi di ASP.NET, WPF, Winforms, app per console, altri servizi.

In questo modo; Ho un layout curato e pulito, lo uso costantemente e ancora, e penso davvero che questo abbia reso il mio codice più pulito e più facile da mantenere.

Questo è stato ispirato da Miguel Castro Extreme WCF screen cast su DotNet Rocks TV con Carl Franklin - cast schermo altamente raccomandato!

Answer 2

Dipende. WCF è un grande framework e ha lo scopo di coprire molti scenari diversi.

Ma per una semplice applicazione come la tua, se non si cura di cose come Java interoperabilità o servizi web generici interoperabilità, questo è quello che faccio:

classi Tutte DataContract e interfacce ServiceContract andare in una libreria (o librerie) che è condivisa tra il client e il server. Nota che probabilmente non dovresti decorare il tuo servizio Implementazione con ServiceContract, dovresti creare un'interfaccia separata con gli attributi ServiceContract che potresti inserire in un assembly condiviso.

Quindi sembra che tu stia facendo tutto bene. Ciò di cui probabilmente non hai bisogno è di generare automaticamente i proxy in questo caso. Ti sta solo causando dolore. Quindi non usare la finestra di dialogo Aggiungi riferimento servizio per quello che stai facendo. Basta includere gli assembly DataContract condivisi e utilizzare ChannelFactory per ottenere un proxy per l'interfaccia di servizio definita nella libreria condivisa. Questo ti impedisce anche di continuare a rigenerare il proxy in Visual Studio, che, per qualsiasi progetto di dimensioni decenti, diventa MOLTO VELOCE.

Se si sta percorrendo questa rotta, è anche possibile eliminare l'endpoint MetaDataExchange, poiché è necessario solo descrivere il servizio al client. Poiché fai tutto in un assembly condiviso, non hai bisogno della descrizione del servizio, dal momento che hai già la descrizione del servizio in forma di codice.

Answer 3

La struttura solito che uso è:

comune - contiene interfacce,-contratti dati, contratti di servizio, classi astratte, ecc; Client - riferimenti Comune, contiene una classe proxy del server; Server - riferimenti Common, contiene classi di implementazione effettive;