Come utilizzare l'unità di lavoro e modelli di repository in un ambiente orientato ai servizi

3

Ho creato un framework applicativo utilizzando l'unità di lavoro e i modelli di repository per il suo livello dati. I livelli di consumer data come la presentazione dipendono dal design del livello dati. Ad esempio un modulo astratto CRUD ha una dipendenza da un repository (IRepository).

Questa architettura funziona come un fascino in ambienti client / server (ad esempio un'applicazione WPF e un server SQL). Ma sto cercando un buon modello per cambiare o riutilizzare questa architettura per un ambiente orientato ai servizi.

Certo che ho alcune idee:

Idea 1: il modello di progettazione "Adattatore"

Conserva l'architettura corrente e crea una nuova unità di lavoro e implementazione del repository che può funzionare con un servizio anziché con l'ORM. I consumatori del livello dati sono strettamente collegati al livello dati, quindi è possibile, ma il problema riguarda l'unità di lavoro; Devo creare un contesto che tiene traccia dello stato degli oggetti sul lato client e invia le modifiche al lato server chiamando "Commit" (Qualcosa che penso che l'RIA abbia fatto per Silverlight). Qui il diagramma:

----------- CLIENT----------- | ------------------ SERVER ----------------------

[ UI ] -> [ UoW/Repository ] ---> [ Web Services ] -> [ UoW/Repository ] -> [DB]

Idea 2: aggiungi un altro livello

Aggiungi un altro livello (diciamo "servizi locali" o "fornitore di dati"), quindi inseriscilo tra il livello dati (unità di lavoro e repository) e i livelli del consumatore di dati (come l'interfaccia utente). Quindi devo riscrivere le classi consumer (CRUD e altre classi che sono dipendenti da IRepository) per dipendere da un'altra interfaccia.

E il diagramma:

----------------- CLIENT ------------------ | ------------------- SERVER ---------------------

[ UI ] -> [ Local Services/Data Provider ] ---> [ Web Services ] -> [ UoW/Repository ] -> [DB]

Si noti che ho il livello dei servizi locali nell'architettura corrente ma non esporre la funzionalità del livello dati. In un'altra parola, il livello dell'interfaccia utente può comunicare con entrambi i livelli di dati e servizi locali, mentre il livello dei servizi locali utilizza anche il livello dati.

|    |      |                 |      |      |
|    | ---> |  Local Services | ---> |      |
| UI |      |                 |      | Data |
|    |                               |      |
|    | ----------------------------> |      |
    
posta Amir Karimi 18.08.2012 - 15:33
fonte

3 risposte

1

Puoi aggiungere l'idea 1 in cima all'idea 2. Quindi vorrei iniziare con l'idea 2

Eviterei di avere una lunga conversazione memorizzata localmente sul client. Risulterà in una complessità di sincronizzazione e il client potrebbe risultare molto loquace (e quindi lento).

Prova a guardare il tuo servizio web come facciata. Prova ad attaccare a una singola chiamata - completa il modello operativo.

Chiediti perché ho bisogno di un'unità client di lavoro.

    
risposta data 25.08.2012 - 14:57
fonte
2

Se smetti di preoccuparti dei tuoi dati e inizi a pensare al tuo modello di dominio, diventerà molto più chiaro. Ora vedo che sei bloccato con unità di lavoro, repository, operazioni sui dati, livelli e adattatori ma ti dimentichi della tua attività.

Quello che suggerirei di fare è di avere un modello di dominio ricco adeguato progettato e avere un livello di servizio che giocherà insieme al tuo dominio per fare il lavoro per la tua azienda. Quando questo è fatto. Tutto ciò che l'interfaccia utente dovrebbe fare è inviare questo DTO del livello di servizio con modelli di input e recuperare i DTO con i modelli di visualizzazione.

    
risposta data 08.10.2013 - 23:40
fonte
0

Direi che il tuo secondo approccio è sulla buona strada. Per me, esporre i repository / uow direttamente al cliente è fragile. Il tuo cliente diventa dipendente dalla meccanica del livello di dominio (e questo diventa esacerbato quando aggiungi diversi client al livello del server).

Esiste un altro modello, Livello servizio applicazioni che fornisce una shell attorno al modello di dominio e funge da intermediario tra il client e il dominio. Ti consente di creare operazioni personalizzate per il cliente e che i dettagli del dominio continuino a essere fluidi senza influire sul client.

    
risposta data 07.09.2012 - 14:44
fonte