decisione wcf: un servizio più contratti o molti servizi

Question

Sto utilizzando .NET 4 per creare un'applicazione client piccolo client per un cliente. Dovrei creare un servizio gigante che implementa molti contratti (IInvoice, IPurchase, ISalesOrder, ecc.) O dovrei creare molti servizi che eseguono un contratto ciascuno su molte porte? Le mie domande sono specificamente interessate ai pro/contro di entrambe le opzioni. Inoltre, qual è il modo comune di rispondere a questa domanda?

Il mio vero dilemma è che non ho esperienza nel prendere questa decisione, e ho poca esperienza con wcf che ho bisogno di aiuto per capire le implicazioni tecniche di tale decisione.

Answer 1

Non creare un servizio di grandi dimensioni che implementa n numero di contratti di assistenza. Questi tipi di servizi sono facili da creare, ma alla fine si trasformeranno in un mal di testa nella manutenzione e non saranno scalabili. Inoltre, si verificheranno tutti i tipi di conflitti di unione del codice se c'è un gruppo di sviluppo in competizione per il check-in/check-out.

Non creare troppi servizi. Evita la trappola di rendere i tuoi servizi troppo raffinati. Prova a creare servizi basati su una funzionalità. I metodi esposti da questi servizi non dovrebbero essere a grana fine neanche. Stai meglio con meno metodi che fanno di più. Evitare di creare funzioni simili come GetUserByID (int ID), GetUserByName (nome stringa) creando un GetUser (utente userObject). Avrai meno codice, manutenzione più semplice e migliore rilevabilità.

Infine, probabilmente avrai solo bisogno di una porta, qualunque cosa tu faccia.

Answer 2

Sembra che si stia mescolando tra DataContract (s) e ServiceContract (s). È possibile avere un ServiceContract e molti DataContract (s) e ciò si adatta perfettamente alle proprie esigenze.

Answer 3

Nelle applicazioni in tempo reale si dispone di un contratto di servizi per ogni entità come fattura, Acquisto e SalesOrder avrà ServiceContract separata

Tuttavia per ogni contratto di servizio ci saranno i clienti eterogenei come fattura sarà chiamato da backoffice attraverso l'applicazione di Windows utilizzando netNamedPipeBinding o netTcpBinding e l'applicazione client in tempo reale è necessario chiamare il servizio utilizzando basicHttpBinding o wsHttpBindings. Fondamentalmente è necessario creare più endpoint per ogni servizio.

Answer 4

È necessario prendere la decisione sulla base del carico previsto, dell'estensibilità necessaria e della prospettiva futura. Come hai scritto "piccola applicazione server client per un cliente", non sta dando una chiara idea dell'uso previsto dello sviluppo in mano. Anche la risposta di Mr. Big deve essere presa in considerazione.

Siete i benvenuti a presentare ulteriori domande sostenute con dati specifici o dettagli sulla situazione in mano. Grazie.

Answer 5

Generalmente si creano servizi diversi per ciascuna entità principale come IInvoice, IPurchase, ISalesOrder.

Un'altra opzione consiste nel separare le query dai comandi. Potresti avere un servizio di comando per ogni entità principale e implementare operazioni commerciali accettando solo i dati di cui hanno bisogno per eseguire l'operazione (evitare operazioni simili a CRUD); e un servizio di query che restituisce i dati nel formato richiesto dal client. Ciò significa che la parte di comando utilizza il modello di dominio/livello aziendale sottostante; mentre il servizio query opera direttamente sul database (ignorando il business, che non è necessario per le query). Questo semplifica molto la tua query e lo rende più flessibile (restituisce solo ciò di cui ha bisogno il cliente).

Answer 6

La verità è che suddividere i servizi WCF o qualsiasi servizio è un atto di bilanciamento.Il principio è che si desidera mantenere una pressione al ribasso sulla complessità pur continuando a considerare le prestazioni.

Più servizi creerai, maggiore sarà la configurazione che dovrai scrivere. Inoltre, aumenterai il numero di classi proxy che devi creare e mantenere dal lato client.

Mettere troppi ServiceContracts su un servizio aumenterà il tempo necessario per generare e utilizzare un proxy. Ma, se si finisce con una o due operazioni su un contratto, si avrà una maggiore complessità del sistema con molto poco da guadagnare. Questa non è una prescrizione scientifica, ma una buona regola empirica potrebbe essere di circa 10-20 OperationContracts per ServiceContract.

L'accoppiamento di classe è ovviamente una considerazione, ma si tratta davvero di preoccupazioni separate? Dipende da ciò che fa il tuo sistema, ma la maggior parte dei sistemi si occupa solo di alcune aree di interesse, quindi suddividere le cose potrebbe non ridurre in realtà l'accoppiamento di classe.

Un'altra cosa da ricordare, e questo è estremamente importante è sempre rendere i metodi più generici possibile. Le offerte WCF in DataContracts per un motivo. DataContracts significa che è possibile inviare qualsiasi oggetto da e verso il server fintanto che i DataContracts sono noti.

Così, per esempio, si potrebbe avere 3 OperationContracts:

[OperationContract] 
Person GetPerson(string id); 

[OperationContract] 
Dog GetDog(string id); 

[OperationContract] 
Cat GetCat(string id); 

Ma, fintanto che questi sono tutti i tipi conosciuti, si potrebbe unire questi per una sola operazione come:

[OperationContract] 
IDatabaseRecord GetDatabaseRecord(string recordTypeName, string id); 

In definitiva, questa è la cosa più importante da considerare quando si progettano contratti di assistenza. Questo vale per REST se si utilizza una serializzazione DataContract come il metodo di serializzazione.

Infine, tornare sui ServiceContracts ogni pochi mesi ed eliminare le operazioni che non vengono utilizzate dai client. Questo è un altro grande!