2016-04-06 14 views

risposta

14

dato uno sguardo alle differenze:

  • Stato analogia: Gli attori lavorano su una singola istanza di un oggetto grafico. I servizi di solito hanno lo stato per più chiamanti.
  • Ambito: Gli attori non possono lavorare da soli, a causa delle loro dimensioni (più come oggetti).
  • del ciclo di vita: Gli attori sono attivi solo quando viene utilizzato, in modo più si adatta alle vostre risorse del server disponibili
  • Concorrenza: Attori applicare l'accesso a thread singolo
  • Stato: Attori basta modificare il aggregato, i servizi di lavoro su insiemi utilizzano spesso le transazioni sui set per il comportamento ACID.
  • Comunicazione: Gli attori comunicano attraverso i canali forniti dalla piattaforma. I servizi possono scegliere diversamente.
  • Accesso: Gli attori nel cluster non possono essere raggiunti dall'esterno per impostazione predefinita . Probabilmente avrai bisogno di un servizio che ti dia accesso.

campioni quando utilizzare un attore:

  • Per ogni utente della tua app mobile si potrebbe avere un attore.
  • Per ogni termostato che invia informazioni alla tua applicazione potresti avere un attore.
  • Per ogni cliente del tuo sito di e-commerce, potresti avere un attore nel cestino della spesa.

Creare un servizio nei casi in cui probabilmente siete abituati. Creare un servizio affidabile che fornisce un servizio per più utenti contemporaneamente. Ad esempio un servizio meteorologico.

+0

grazie per questo, quindi diciamo se stavo sviluppando un'applicazione di inventario online semplice libro, quali sarebbero i servizi e quali sarebbero gli attori? – spdev

+0

Abbastanza difficile da dire senza più contesto. Gli utenti finali possono noleggiare o acquistare libri? Qual è il business case? Quando hai funzionalità per gli utenti finali, potresti avere un attore per utente finale. Forse anche per libro, ma dipende. –

+0

La nota sulla scala non è vera. Reliable Actors è un framework in cima ai servizi affidabili, in modo che si adattino esattamente allo stesso modo. Gli attori sono limitati dalle risorse del server allo stesso modo dei Servizi. –

5

Non intendo usare una parola per definire se stessa, ma utilizzare Reliable Actors solo se hai determinato che il tuo problema si adatta allo schema di progettazione dell'attore. Gli attori sono un modello di design molto simile a molti dei modelli di design Gang of Four. Se il tuo problema si adatta a uno dei modelli, usalo. Se non lo fa, è meglio non provare a calzare il tuo problema nel modello sbagliato.

In Service Fabric, gli attori affidabili sono un'implementazione del modello di attore virtuale. Ha alcune regole di funzionamento e avvertenze che vanno con loro.Questo è un buon documento da leggere per avere un'idea di come funziona il framework Reliable Actor e se soddisfi o meno i requisiti: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-platform/

Gli attori affidabili sono in realtà solo un framework costruito in cima a Servizi affidabili, quindi tutto il si applica la stessa regola di ridimensionamento, partizionamento e distribuzione: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-platform/

+1

Hai lo stesso link due volte. – mayu

+1

Quali sarebbero i problemi che si adatterebbero nel modello di progettazione degli attori? – stack247

+5

È divertente, nessuno su Internet può dare un esempio chiaro, conciso, reale del perché si dovrebbe usare un servizio contro un attore. Ho letto la documentazione e l'articolo di wikipedia sugli attori e sono ancora completamente confuso. –

Problemi correlati