Quante entità deve includere il servizio del dominio RIA?

Question

Mi chiedevo su come implementare esattamente servizio di dominio in RIA. È comune includere tutte le entità nell'intero modello di dominio in un singolo servizio di dominio, rendendo così il servizio responsabile per l'intero database? È così che normalmente è fatto? Ho davvero alcun motivo per separare l'accesso ai dati in servizi diversi, ma mi chiedevo se questa è considerata una buona pratica, e quali sarebbero i pro ei contro di un tale approccio.

Inoltre, è considerata una buona o una cattiva pratica registrare il contesto di dominio come un singleton con IOC, in modo che l'intera applicazione lavori con lo stesso insieme di dati, evitando così problemi di concorrenza e problemi simili?

Pensieri?

Grazie

Answer 1

Abbiamo due servizi separati nella nostra applicazione: uno per il modello di dati e uno strettamente utilizzato per l'autenticazione. Abbiamo preso questo progetto dalla struttura dell'app campione aziendale di MS.

Abbiamo preso in considerazione la possibilità di suddividere il nostro servizio di dominio dei dati in componenti più piccoli, ma abbiamo deciso contro di esso perché non sembrava aggiungere alcun vantaggio (oltre a ridurre le dimensioni della classe di servizio). Se si dispone di modelli di dati distinti completamente indipendenti da ciascuno altri, allora, quella direzione potrebbe avere senso. Intuitivamente il servizio di dominio dovrebbe rappresentare l'intero dominio. Se i domini sono indipendenti (con il occasional need for crossover) allora ha senso logico per separare loro in quel modo.

Per quanto riguarda utilizzando il contesto come Singleton: ho provato e finito per la creazione di istanze di classe portata invece. Non abbiamo riscontrato alcun problema in questo modo poiché tutti utilizzano la stessa connessione dati sottostante. Non so quale sia la migliore pratica "ufficiale", ma è il modo in cui l'ho vista in numerose app RIA.

Answer 2

Grazie Nick. In realtà ho fatto la stessa cosa di te, ho creato due servizi, uno per l'autenticazione e uno per l'accesso ai dati. Mi sembra molto logico.

Per quanto riguarda il datacontext come singolo, ho provato anche questo e funziona bene. Non c'è bisogno di ricaricare e aggiornare costantemente i dati e preoccuparsi dei problemi di concorrenza in altre classi :)