Utilizzo di WCF come API per l'accesso al database tramite la GUI o no?

Naviga le tue risposte
4

Originariamente ho posto questa domanda su Stackoverflow ma mi è stato suggerito di spostare la domanda qui.

Ho fatto questa domanda qualche tempo fa nei forum MSDN ma mi piacerebbe una seconda opinione di StackOverflow da quando ho provato questa strada e ho trovato alcuni CONS, ma mi piacerebbe sentire anche altre opinioni.

Scenario:

Ho un programma di servizio Windows, estraendo dati da file e inserendo i dati estratti in un database MS SQL. C'è un programma GUI che esegue alcuni filtri e calcoli e visualizza i dati SQL in tempo reale. Quindi la GUI mostra fondamentalmente record selettivi dal database in qualsiasi momento. Dovrebbe anche essere possibile per la GUI inserire e aggiornare i record in base alle regole. Anche i dati recuperati dal Database possono essere enormi e sarebbe anche bello consentire l'accesso remoto ai dati dalla GUI (non critico)

Quindi la mia domanda in maggiori dettagli:

1 - dovrei creare un servizio WCF nel mio programma di servizio che fornisce alcune API alla GUI per accedere e aggiornare i record?

Pro:

  • Posso modificare il database di back-end e non è necessario aggiornare la GUI app.
  • La GUI sarebbe sql gratuita.
  • consente alla GUI di accedere direttamente al database e recuperare e aggiornare stesso.

2 - consente alla GUI di accedere direttamente al database e recuperare e aggiornare se stesso. PRO:

  • sicurezza già presente più veloce dell'opzione 1 più semplice da implementare

  • modificato nei record può attivare la modifica dei dati anziché il polling    nuovi dati per la visualizzazione in tempo reale.

  • La GUI può accedere ai dati remotly se l'accesso al database SQL è configurato per essere accessibile remotamente (un possibile rischio per la sicurezza?)

questa è la domanda originale: link

    
posta ArmenB 22.05.2012 - 20:57
fonte

1 risposta

2

In genere preferisco avere un buon livello di servizio tra due dipendenze, a meno che non sia possibile. Sono un grande sostenitore del TDD, ed è molto più facile testare qualsiasi cosa tu possa prendere in giro o fingere per controllare meglio il comportamento per il quale vuoi testare. Provare a simulare SQL Server non è facile come deridere un servizio. Inoltre, le GUI sono notoriamente difficili da testare con qualsiasi tipo di coerenza, dato che di solito cambiano e a volte sono molto non deterministiche (eventi multipli che causano esiti multipli, ecc.). Con un servizio, hai la possibilità di creare un servizio di simulazione che implementa l'interfaccia / contratto. Se fatto bene, è quindi possibile prendere tempo a sviluppare la GUI e scrivere test per questo prima di dover elaborare lo schema del database e il servizio Windows. Vorrei anche vedere che forse il servizio Windows aggiorna il database attraverso un livello di servizio di qualche tipo. Non deve essere necessariamente un servizio "web". In un certo senso, ho avuto fortuna con questo tipo di cose che sono state fatte attraverso un bus dei messaggi. Abbiamo utilizzato EMS di TIBCO, ma è possibile utilizzare facilmente qualsiasi implementazione JMS e un connettore .NET. Il vantaggio di questo tipo di configurazione è che è possibile scrivere i dati dei file in una coda, disporre di un servizio che preleva i dati dalla coda e aggiorna il database E notifica la GUI del client per aggiornare i propri dati. Una variante di questa configurazione potrebbe essere che il servizio invia effettivamente i dati ai client tramite questo argomento, risparmiando la larghezza di banda aggiuntiva di avere più client (se li hai) da dover colpire il database con una query su ogni aggiornamento.

    
risposta data 22.05.2012 - 21:33
fonte

Leggi altre domande sui tag

Come faccio ad architetto 2 plugin che condividono un componente comune? Hai bisogno di aiuto con il piano di migrazione del sistema