[c#] comunicazione servizio, applicazione

[VaSa]

Ciao a tutti!

sto sviluppando un progetto in c#. purtroppo sono alle prima armi con la programmazione c#.
Quello che vorrei/dovrei realizzare è un servizio che legge dati provenienti da periferico. questi dati dovranno poi essere passati ad una applicazione che li elabora e li presenta a video . Più in dettaglio la mia idea era questa:

fare un servizio che faccia da interfaccia tra h/w e software applicativo che elabora i dati in arrivo dal servizio. Quindi mi troverei ad avere un architettura client server in cui il client è l'applicazione che elabora i dati e il server è il servizio. ogni tot tempo il client interroga il servizio legge i dati, li elabora, e tira su una finestra di pop up (stile quella di avast).
Questo programma non deve funzionare in rete ma in locale.

quello che non so è:
1) quale sistema mi conviene utilizzare per far comunicare il servizio con l'applicazione?
ad esempio wcf potrebbe andare bene o meglio usare altri sistemi offerti dal framework .net quali?
2)una volta installato il programma all'accensione del pc dovrebbero partire sia il servizio(e su questo non ci dovrebbero essere problemi perchè viene fatto in automatico) ma anche l'applicazione che leggi i dati dal servizio. Come faccio a far partire questa applicazione?
posso metterla in "esecuzione automatica" e sono a posto oppure devo dire al servizio che appena parte deve far partire l'applicazione?

grazie a tutti quelli che risponderanno!!

[oregon]

In genere un servizio si sceglie perché deve "lavorare" anche in assenza di un utente per gestire continuamente delle informazioni in arrivo (e fin qui, comprendo il perché tu voglia utilizzarlo).

Ma l'applicazione sempre attiva non la capisco.

[VaSa]

Grazie per la risposta!!

il motivo per cui pensavo di fare l'applicazione sempre attiva è dato dal fatto che in questo modo il servizio si occupa solo di fare da interfaccia tra applicazione e h/w! in pratica il servizio in questo modo mi espone solo i dati che legge dall'hw! l'applicazione interroga ogni tot tempo il servizio ed è necessario che lo faccia perchè questi dati variano di continuo e occorre fare statistiche sui dati!
Capisco che l'obiezione potrebbe essere data dal fatto che il servizio oltre che catturare i dati faccia anche la parte di logica (che secondo il mio modello dovrebbe essere fatta dall'applicazione) e quindi quando i dati sono pronti allora il servizio mi risvegli l'applicazione grafica cioè mi presenti il form(tra l'altro ho letto che è una pessima abitudine questa). Però in questo modo secondo me è complicato il mantenimento del codice perchè separando l'interfaccia con l'hw ,cioè il servizio, a livello applicazione posso solo occuparmi della logica sui dati trascurando i dettagli sottostanti => nel momento in cui mi accorgo che ci sono dei problemi di logica non devo bestemmiare con i dettagli dell'hw!!

spero di essermi spiegato!

[oregon]

A parte il fatto che potresti scrivere due servizi, uno che gestisca il dialogo con l'hardware e l'altro che calcoli le statistiche, dovresti chiarire un po' il contesto del problema.

Di che tipo di dati si tratta? In che quantità o in quale frequenza vengono acquisiti? Che tipo di calcoli/statistiche devi farci e come e quando devi presentare i dati?

[VaSa]

scrivere due servizi non mi risolve il problema perchè poi devo far comunicare il servizio "statistiche" con la grafica e quindi sono da capo!

il numero di dati catturati variano a seconda della situazione in cui mi trovo! posso dire che in media ne catturo un 40 dati ogni 1 o 2 secondi!

il discorso è: leggo i dati, verifico se ci sono alcune condizioni particolari se ci sono allora faccio "alzare" un pop up sul desktop dell'utente. (nota che è finalizzato all'utente se non c'è l'utente non ha senso di esistere il programma).

la mia architettura è studiata in questo modo solo perchè ho letto su molte guide/forum che non è consigliabile che sia il servizio a svegliare un form grafico!! perchè potrebbe non essere visualizzato in alcune situazioni!


Purtroppo non posso essere troppo dettagliato sul progetto!

grazie ancora per la risposta!

[oregon]

A questo punto, penso sarebbe meglio che facesse tutto l'applicazione, con molti thread.

[VaSa]

si ci ho pensato anche io! però "sono obbligato" ad usare i servizi
per caso sai dirmi se ha senso ed è semplice usare wcf per far comunicare servizio ed applicazione?

[oregon]

Obbligato? Allora la discussione è inutile ...

Il servizio può comunicare semplicemente tramite socket o memoria condivisa.

Ovviamente puoi usare wcf anche se il suo può essere più "articolato" (se fatto bene, si può presumere un tempo di sviluppo maggiore)

[VaSa]

non è inutile se aiuta a vedere le cose da punti di vista diversi! comunque un altro valido motivo pratico,secondo me, per usare il servizio è dato dal fatto che nel momento in cui io non lavoro più sul progetto chiunque può cambiare le regole ad alto livello semplicemente interfacciandosi con questo.

grazie per la risposta! attendo comunque altri pareri più idee si hanno meglio è!

[MItaly]

Ai tempi avevo un po' studiato le funzionalità di remoting del .NET, che, un po' alla maniera di DCOM, Corba e compagnia, consente di accedere ad oggetti situati nel processo server da un client, usando (ad esempio) i socket come layer di trasporto. Suppongo che WCF sia l'evoluzione di questa roba, che potresti usare per la comunicazione tra servizio e applicazione.
La scelta comunque dipende molto dal tradeoff performance/facilità d'uso che serve per il tuo programma - la memoria condivisa, ad esempio, è la cosa più veloce, ma se non sincronizzi in maniera corretta è un fiorire di race conditions e heisenbug; dall'altro lato, una soluzione tipo WCF dovrebbe rendere abbastanza trasparente il fatto che tu stia operando con oggetti che stanno in un altro processo, ma non credo che abbia performance analoghe.