Progetti WCF multipli rispetto a progetto singolo in soluzione

Question

Attualmente nella nostra soluzione sono presenti 12 progetti WCF. Ogni progetto è essenzialmente il proprio endpoint. Ad esempio, il progetto WCF "Ordine" è l'endpoint Order.svc. Questi 12 endpoint sono esposti da un singolo progetto WebHost. Il progetto WebHost ha 12 file .svc che puntano a ciascun assembly/spazio dei nomi corrispondente.

La mia domanda ruota attorno all'uso di un progetto (un assemblaggio ... una dll) rispetto a più progetti (più assiemi ... più dll). Quali sono i vantaggi/svantaggi, se del caso? Il risultato finale è lo stesso ... hai un progetto WebHost che espone questi endpoint che puntano a un assembly/spazio dei nomi. Tranne che devi solo gestire una .dll contro 12 .dll nella directory bin.

Per me i vantaggi di un progetto: Manutenibilità: invece di 12 progetti, ciascuno con più riferimenti alle nostre interfacce, datacontracts, utility, ecc., Abbiamo un progetto che ha i riferimenti impostati in UNO punto. Quindi possiamo distribuire l'una DLL e utilizzare un bilanciatore del carico per distribuire uniformemente. Anche se ospitiamo esplicitamente 3 servizi per server (quindi, 4 server), se un server va giù il bilanciamento del carico può essere regolato e gli altri 3 server avranno ciò di cui hanno bisogno e si prenderanno cura di tutto automaticamente. (Suppongo che lo stesso è vero con 12 .dll's ... basta assicurarsi che tutte le 12. Dll siano su ciascun server).

Tempo di costruzione: meno progetti = tempo di costruzione più rapido. Visual Studio non ha bisogno di eseguire tanto il collegamento e la copia. Dll è dappertutto. Tempo di costruzione più rapido = sviluppatore più produttivo e una build e implementazione più rapida.

Attualmente ho un paio di colleghi interessati a "accoppiare strettamente" tutti i nostri servizi WCF in un unico progetto. Per me, sono tutti servizi WCF perché non li mettono nello stesso progetto? Gli endpoint (file .svc) sono ciò che li separa. Ho anche sentito la domanda, "che dire del blocco morto?". Che ne pensi? È un problema/preoccupazione valido? (Onestamente non lo so)

Ci sono anche state delle domande su se il file .dll si corrompe. Se lo è, allora tutti i servizi sono giù. Ancora una volta ... è una preoccupazione valida?

Tutti gli esempi che ho visto da Microsoft e altri hanno i servizi WCF in un progetto separati da classi diverse. Le interfacce sono nel loro stesso progetto ... datacontracts in un altro progetto e così via.

Quindi, qual è la tua opinione? Come organizzi più servizi WCF nella tua soluzione Visual Studio? Imparami.

Answer 1

Abbiamo imparato questo nel modo più difficile. Recentemente abbiamo avuto un progetto in cui abbiamo iniziato con ciascun servizio nel suo progetto e abbiamo finito per convertire tutti i servizi nello stesso progetto. I principali problemi con le cose nei diversi progetti sono:

• Distribuzione: si creano pacchetti da 12 msi uno per ciascun servizio, verranno distribuiti in siti Web separati. Cosa pensano le opperations sull'esecuzione di 12 script di installazione e sul monitoraggio di 12 siti.
• I servizi si chiamano a vicenda, se sì, su WCF può essere lento e la configurazione può essere un incubo, 12 servizi che chiamano 11 servizi, con configurazione per dev, test e prod.
• Anche in servizi che si chiamano l'un l'altro c'è un calo di prestazioni rispetto a una chiamata di chiamata diretta
• I servizi hanno una versione comune, quando per esempio le modifiche al database cambieranno tutti i servizi. In caso affermativo, sarà necessario distribuire tutti i servizi.Questo richiede più tempo di un singolo servizio, i tempi di inattività saranno più lunghi

Utilizziamo progetti separati per oggetti di interfaccia (contratti) e di trasferimento dati.

Answer 2

In genere se i miei file svc esistono nello stesso assembly, quindi condividono alcuni scopi. Se lo svc condivide lo stesso scopo comune per esistere nello stesso assembly, l'implementazione condivide anche lo scopo comune di esistere in un singolo assembly.

Non c'è alcun problema con averli in assemblaggi separati, ma non c'è alcun vantaggio neanche. Si tratta più di costruire una soluzione chiaramente strutturata e manutenibile - ed è in gran parte una questione di preferenza personale/standard/stile.

Separare le implementazioni se si desidera separarle normalmente, ovvero se forniscono risultati significativamente diversi o agiscono come componenti separati della soluzione. Se il singolo assemblaggio risultasse poco maneggevole, allora separalo.

Concentrarsi maggiormente su contratti e implementazioni. Servono a scopi diversi (tecnici) e potresti voler esporre i contratti senza esporre le implementazioni.

Detto questo, preferisco averli in un unico assembly ma separati da un namespace chiaro. Meno assiemi sono spesso più facili da gestire.

Answer 3

Ricorda che non è necessario distribuire i progetti nello stesso modo in cui gestisci il loro sviluppo. Puoi sempre usare cose come ILMerge per mutiple dll in una dll, come parte di un passo di costruzione.

Io consiglio sempre di sviluppare alcuni servizi utilizzando la Software Factory (ovvero la Web Software Factory Factory), http://servicefactory.codeplex.com/ che aiuta a far rispettare una serie di "best practice" dal team di Pratiche MSFT Patterns &. È un ottimo modo per imparare alcune buone pratiche, ma una volta apprese, di solito è meglio/più facile applicarle con una buona guida/revisione del codice con il tuo team di sviluppo. In questo modo puoi usare ciò che funziona nel tuo ambiente e non usare ciò che ti intralcia.

Se si dispone di 12 servizi, come si gestisce l'inferno di configurazione che può verificarsi? Soprattutto quando si dispone di servizi che dipendono da altri servizi. Eventualmente inserire tutto ciò e tutti i collegamenti e comportamenti personalizzati nella configurazione può essere un incubo di implementazione. Inoltre, come rendi noti i tuoi servizi agli altri in azienda? Tutto è fatto tramite passaparola, buona gestione della build e controllo del codice sorgente?