Servizio WCF con metodi per recuperare i dati

2

Sto pensando di creare un servizio WCF che recuperi le entità dati da un database Sql Server. E attualmente sto combattendo con i problemi delle migliori pratiche.

Il fatto è che ci sono diversi modi in cui un utente può recuperare dati diversi. Ad esempio, gli ordini dei clienti possono essere ottenuti da un intervallo di date, ma questo intervallo di date potrebbe essere applicato alla data di elaborazione del comando, alla data di scadenza o alla data di spedizione effettiva.

Se le app client parlassero direttamente con Sql Server, sarebbe abbastanza semplice. Ma ora con WCF sento di dover apportare cambiamenti di servizio ogni volta che voglio introdurre un nuovo modo di interrogare i dati (nuova API di servizio). Questo significa dover smontare il servizio, perdere lo stato, aggiornarlo e riavviarlo.

Ovviamente potrei passare una stringa di filtro ai miei metodi di servizio, ma la sicurezza non sembra essere una buona idea.

Come è probabile che tu sappia ora sono abbastanza verde con WCF e probabilmente c'è qualcosa che mi manca. Qualsiasi consiglio sarebbe molto apprezzato.

    
posta Crono 18.06.2015 - 15:19
fonte

2 risposte

2

Non c'è niente di sbagliato nell'avere metodi distinti nel tuo servizio web. Questo rende il servizio un contratto molto esplicito e dovrebbe essere facile da usare per i tuoi clienti. Ad esempio, il tuo servizio iniziale potrebbe avere:

  • GetDeadlineOrders
  • GetProcessedOrders

Se devi aggiungere un altro metodo in futuro come:

  • GetExpiredOrders

Il tuo servizio è compatibile in modo compatibile in modo tale che il client esistente non venga effettuato e i client che desiderano utilizzare la nuova funzionalità possono farlo.

Il modo più facile per manange è con il versioning come @BatteryBackupUnit ha menzionato prima. Eseguendo versioni diverse i client possono eseguire l'upgrade in futuro senza essere costretti ad eseguire l'upgrade quando viene distribuito il servizio.

C'è solo un URL diffferente, nel passato esempio i servizi potrebbero essere:

  • link (Ha metodi elaborati e scadenza)
  • link (Ha processi, scadenza e metodi scaduti)

Si tengono solo le versioni N disponibili e si scaricano le versioni inferiori in base alle esigenze, dando ai clienti un sacco di preavviso.

L'altro modo è progettare un metodo più generico:

  • GetOrders

Questo metodo prenderebbe un altro parametro / oggetto che avrebbe i dettagli necessari per formulare la query. Un modo per implementare metodi generici consiste nell'utilizzare un dizionario di coppie nome / valore nel contratto in modo che possa essere esteso senza modificare lo schema. Ciò rende il servizio meno esplicito e più difficile da usare perché ora il client può realmente passare qualsiasi coppia nome / valore nella chiamata di servizio e spetta al codice analizzarlo e creare la query corretta al database.

Se il servizio cambierà frequentemente, potrebbe essere meglio fare il percorso generico in modo che il contratto non cambi mai. Tenete presente che con una definizione del contratto così sciolta potrebbero esserci più richieste di errori e incomprensioni tra cliente / servizio.

Se ci sono versioni pianificate, come ogni trimestre, avere uno schema definito con versioni diverse sarà OK e più facile da usare. Basta la versione delle versioni e rendere il servizio compatibile e dovrebbe andare bene.

    
risposta data 18.06.2015 - 16:09
fonte
0

No, penso che tu abbia ragione. Ovviamente puoi anche progettare la tua interfaccia per essere più flessibile in merito alle query. Chiamiamolo "design ahead". Ma ovviamente questo è in conflitto con YAGNI. Quindi dovrai scendere a compromessi.

Un'altra alternativa sarebbe quella di eseguire la vecchia e la nuova versione del servizio su porte / URL diversi, eliminando così i tempi di fermo. Dovrai comunque passare da "vecchi" clienti a "nuovi" clienti a un certo punto, ma forse in un momento più conveniente. Ovviamente questo comporta anche più SW e complessità di implementazione che si traducono in costi più elevati.

Quindi, finché puoi vivere con i tempi morti, probabilmente è solo la strada da percorrere.

    
risposta data 18.06.2015 - 15:38
fonte

Leggi altre domande sui tag