2009-06-16 21 views
27

Quando dovrei andare per un servizio di Windows e quando dovrei andare per una "Applicazione in background" che viene eseguita nell'area di notifica?Windows Service vs Windows Application - Best Practice

Se non sbaglio, la mia decisione di progettazione sarebbe, qualsiasi app che deve essere in esecuzione prima che l'utente possa accedere al computer dovrebbe essere un servizio. Per tutto il resto usa un'app di sfondo. La mia decisione è giusta?

Inoltre, se ho bisogno di "privilegi di amministratore" per la mia app in background, vorrei eseguire l'escalation utilizzando un manifest. Ci sono altri vantaggi specifici nell'esecuzione come servizio?

risposta

22

mie regole generali sono le seguenti

  • Se ha bisogno di correre sempre, si tratta di un servizio.
  • Se deve essere eseguito con un particolare account utente, Servizio di rete, Sistema locale, generalmente è un servizio (o un'applicazione COM +)
  • Se l'utente ha bisogno di un controllo su di esso, è generalmente un'applicazione di area di notifica.
  • Se ha bisogno di informare l'utente di qualcosa, si tratta di un'applicazione nell'area di notifica

Il divertimento arriva quando si ha la necessità di eseguire qualcosa come un account di sistema, ma anche interagire con esso. IIS è un buon esempio di questo, è un servizio, ma l'amministrazione è un'applicazione - deve essere in esecuzione all'avvio, ha bisogno di accedere a particolari cose che un utente non può accedere normalmente (c: \ inetpub), ma il l'utente deve essere in grado di avviarsi, fermarsi e configurarlo.

+0

Il divertimento arriva quando si ha la necessità di eseguire qualcosa come account di sistema, ma anche di interagire con esso. Questo è il mio problema in realtà ... Sto cercando di scaricare le informazioni del registro dal mio servizio e analizzarle sulla mia app di Windows che avvisa l'utente ... non sono sicuro che il mio progetto sia giusto ... – Mugunth

+1

Ah, c'è una moltitudine di modi per farlo, la mia preferenza, perché li uso così tanto, è che il servizio ospiti un endpoint di WCF e lo controlli in quel modo. – blowdart

+4

Vorrei aggiungere all'elenco: Se deve essere eseguito senza che un utente abbia effettuato l'accesso al computer, è un servizio. –

3

Credo che la tua decisione sia quasi giusta, tuttavia, aggiungerei un'altra condizione. Prendiamo ad esempio il servizio mysqld (in questo caso puoi scegliere, ma la maggior parte delle persone lo esegue come servizio). Viene eseguito come servizio perché si desidera accedere al servizio in qualsiasi momento attraverso potenzialmente più applicazioni. È importante che sia reattivo a tutte le applicazioni che lo invocano e, di per sé, non è molto di nulla, se non aspettare di servire altre applicazioni.

Solo qualcosa che prenderei in considerazione quando prendo la mia decisione.

5

Progettare un'applicazione come servizio se l'applicazione ha uno scopo critico e non dovrebbe mai (o raramente) essere chiusa. I servizi di Windows offrono buone opzioni di ripristino di emergenza, buone notifiche (vedere la scheda Ripristino nella proprietà del servizio).

anche un buon motivo per utilizzare i servizi è perché può essere eseguito in qualsiasi utente (quindi se distribuirli su un server che si remoto, si può tranquillamente effettuare il logout dopo aver avviato il servizio senza worring che l'applicazione verrà chiusa pure).

Inoltre, progettiamo servizi in combinazione con un'applicazione desktop in grado di interagire con il servizio e può essere utilizzato per monitorare o riconfigurare il servizio durante l'esecuzione. In questo modo puoi avere tutti i vantaggi di un'applicazione vassoio, nel tuo servizio.

Tuttavia, non si dovrebbe abusare dei servizi e usarli, come ho detto, solo per applicazioni cir- coliche.