Interazione di un'applicazione basata su GUI e di un servizio di Windows

Naviga le tue risposte
1

Sto lavorando su un progetto personale che sarà progettato per aiutare a gestire la mia libreria multimediale, in particolare le registrazioni create da Windows Media Center.

Quindi avrò le seguenti parti per questa applicazione:

  • Un servizio Windows che monitora la cartella di registrazione. Una volta completata una nuova registrazione che soddisfa criteri specifici, chiamerà diverse applicazioni CLI di terze parti per rimuovere gli spot pubblicitari e ricodificare il video in un formato più intuitivo.
  • Una GUI del controller per poter modificare le impostazioni del servizio, in particolare aggiungere nuovi spettacoli da guardare e modificare i parametri per le applicazioni CLI
  • Un'applicazione desktop autonoma (basata su GUI) in grado di eseguire molte delle stesse funzioni del servizio Windows, si aspetta manualmente su file specifici anziché automaticamente in base a criteri specifici.

(Va detto che ho un'esperienza limitata con un'applicazione di questa complessità e non ho assolutamente esperienza con i servizi di Windows)

Poiché il primo e il terzo proiettile condividono funzionalità simili, il mio piano di progettazione è quello di estrarre la funzionalità comune in una libreria separata condivisa da entrambe le parti dell'applicazione, ma questi 2 componenti non hanno bisogno di interagire diversamente.

Il secondo e il terzo proiettile sembrano condividere alcune funzionalità comuni, entrambi avranno una GUI, entrambi dovranno aiutare a definire parametri simili (uno da inviare al servizio e l'altro da inviare direttamente alle applicazioni CLI), quindi può vedere qualche vantaggio combinarli nella stessa applicazione.

D'altra parte, l'applicazione standalone (bullet # 3) non ha davvero bisogno di interagire con il servizio, tranne forse per condividere alcuni parametri predefiniti comuni che possono essere facilmente inseriti in un XML in una posizione comune, quindi sembra più sensato tenere tutto separato.

La GUI del controller (2 ° punto) è il punto in cui sono bloccato al momento.

  • Eseguo il rollover di questa funzionalità (consenti all'utente l'interazione con il servizio per aggiornare impostazioni e criteri) nell'applicazione standalone? O sarebbe meglio prendere una decisione sul design per tenerli separati? Nello specifico, sono preoccupato di aggiungere la complessità della comunicazione con il servizio Windows all'applicazione standalone quando non ne ha bisogno.
  • È WCF l'approccio giusto per consentire all'interfaccia grafica del controller di interagire con il servizio di Windows? O c'è un'alternativa migliore? Al momento, non immagino la necessità di una quantità significativa di interazione, magari aggiungendo un nuovo compito una volta ogni tanto e occasionalmente modificando un parametro, ma quando qualcosa viene cambiato, mi aspetto che il servizio Windows utilizzi immediatamente il nuove impostazioni.
posta psubsee2003 10.12.2012 - 10:01
fonte

2 risposte

1

Consiglierei di guardare ASP.NET MVC invece di usare WCF. I servizi ASP.NET sono generalmente più facili da configurare e da eseguire, e non sembra che tu abbia bisogno della complessità aggiuntiva che WCF può offrire. Se sei preoccupato per la sicurezza, esegui i servizi ASP.NET su https e dovrebbe essere sufficiente per il tuo utilizzo.

Per il controller che hai descritto, sta a te decidere cosa serve e come strutturarlo. Se sei preoccupato di aggiungere complessità inutili a una delle due interfacce utente, non farlo. È sempre possibile aggiungere tale funzionalità in un secondo momento quando è effettivamente necessario. Fallo funzionare prima di preoccuparti di aggiungere l'ultimo campanello e fischietto nell'applicazione.

Si arriva a un punto mentre si costruisce l'applicazione a dove avrà senso tenere separate le due interfacce utente o unirle tra loro. Non conoscerai davvero la risposta fino a quando non avrai scritto la domanda. Potresti scoprire che un'applicazione con due schede risolve quel particolare problema per te.

    
risposta data 10.12.2012 - 16:14
fonte
1

Il termine usato per l'interazione tra programmi sulla stessa macchina è "comunicazione tra processi" - questo dovrebbe aiutare a cercare le opzioni. Questa risposta suggerisce che WCF è la tua migliore opzione (ti permetterà di usare pipe con nome per il trasporto dei dati, che è più efficiente per le tue esigenze di HTTP).

Il fatto di dividere le tue applicazioni della GUI è una questione di preferenza - riguarda esclusivamente l'usabilità, specialmente dal momento che sei l'utente principale (solo?). Pesare i benefici di ciascuno. Ad esempio:

  • Separato: è più facile arrivare esattamente a ciò che si vuole fare (pensa ai tuoi casi d'uso e quanto spesso ciascuno sarà usato). Semplici interfacce utente: nessuna confusione con i controlli non correlati all'utilizzo corrente.

  • Insieme: un'app da distribuire. Un'app per trovare e lanciare. Non si apre accidentalmente quello sbagliato.

Gli elementi di codice o GUI condivisi non dovrebbero essere una considerazione: possono essere condivisi tramite una DLL con la stessa facilità con cui venivano utilizzati nello stesso progetto.

Un'alternativa è combinare tutto, incluso il servizio, in un'unica GUI, che si riduce all'area delle notifiche e si avvia all'avvio di Windows. La porzione "servizio" potrebbe essere eseguita in un thread in background e si potrebbe avere un menu di scelta rapida sull'icona di notifica per aprire la finestra di dialogo delle impostazioni o per avviare un'esecuzione manuale. Ciò sostituisce la necessità di comunicazione tra processi con la comunicazione inter-thread, che è più semplice per funzionare.

    
risposta data 10.12.2012 - 22:16
fonte

Leggi altre domande sui tag

Che cosa sono gli ambienti di runtime Web e i linguaggi di programmazione Alla ricerca di sviluppatori per la collaborazione nel progetto open source aziendale [chiuso]