Progettazione di servizi orientati al dominio e architettura dei servizi WCF

Question

Progettazione di servizi orientati al dominio e architettura dei servizi WCF

#1 da (2 voti)

5

Sto cercando di capire come architettare il mio progetto nel paradigma DDD (un principiante completo in DDD) e sono incappato in un problema sull'implementazione dei servizi web ... Queste sono alcune opzioni che vedo:

Fat client, Fat server (opzione 1):

Server:
- Livello repository: parla al database e può restituire oggetti di dominio.
- Livello dominio: contiene oggetti di dominio con logica aziendale e convalide.
- Livello di servizio: agisce come una facciata sul livello del dominio.
- Livello WCF: espone il livello di servizio ai metodi web. Associa gli oggetti del dominio agli oggetti DTO appropriati.
Cliente:
- Livello infrastruttura: comunica con il server tramite i servizi WCF. Associa gli oggetti DTO agli oggetti del dominio.
- Livello dominio: contiene oggetti di dominio con logica aziendale e convalide.
- Livello di servizio: agisce come una facciata sul livello del dominio.
- Livello UI (WinForms): utilizza il livello di servizio per comunicare con gli oggetti di dominio.

Bene: poiché il livello del dominio è sia sul client che sul server, le convalide avvengono su entrambi (buono per i client - riduce il numero di chiamate al server, buono per il server - a causa di "non fidarsi mai dei dati dell'utente").

Bad: la convalida avviene due volte, è necessaria molta mappatura (ad esempio una semplice query al database: dominio (restituito dal repository) - > DTO (necessario per WCF) - > dominio (necessario per il livello del dominio sul client ) - > DTO (per WinForms). Eventuali modifiche nel dominio devono essere implementate contemporaneamente su server e client. Complicato?

Fat client, thin server (opzione 2):

Server:
- Repository: parla al database e restituisce oggetti DTO.
- Livello WCF: espone le chiamate al database ai metodi Web.
Client: esattamente come nell'opzione 1.

Bene: sul client posso trattare i servizi WCF come un normale repository che restituisce oggetti DTO. Più semplice come opzione n. 1.

Cattivo: è corretto che il repository funzioni su DTO-s anziché su oggetti dominio? Inoltre, il server non esegue alcuna convalida, quindi deve fidarsi dei client dei dati.

Thin client, fat server (opzione 3):

Server: esattamente come nell'opzione 1.
Cliente:
- Livello infrastruttura: comunica con il server tramite i servizi WCF.
- Livello UI (WinForms): utilizza i relatori per comunicare con il server tramite chiamate WCF nel livello infrastruttura.

Buono: tutta la logica di dominio è sul server.

Bad: il client non contiene alcuna convalida, quindi può effettuare molte chiamate inutili al server.

Mi sto appoggiando alla mia prima opzione, ma sembra che io stia complicando le cose ... Qualche consiglio o altre opzioni?

c# domain-driven-design architecture .net wcf

posta sventevit 04.04.2014 - 12:36

fonte

1 risposta

Leggi altre domande sui tag c# domain-driven-design architecture .net wcf

Qual è il modo migliore per esporre un oggetto Model in un ViewModel? Uso di std :: sort et al. con una routine di confronto definita dall'utente

score 2 · Answer 1

Vorrei andare con l'opzione 3, con le seguenti note:

Prova a ridurre la quantità di logica di dominio che i tuoi clienti devono sapere per portare a termine il lavoro. Crea servizi che espongono tali dati in modo significativo (ai tuoi clienti), in modo che tu possa richiedere raccolte di oggetti di dominio che soddisfano determinati criteri, piuttosto che fare questo scricchiolio sul tuo cliente.
La convalida deve essere considerata facoltativa sul lato client, poiché non è mai possibile garantire che le future implementazioni client vengano eseguite correttamente. Pertanto, convalidare sempre sul lato server come se non fosse stato fatto altrove. Ovviamente, i client dovrebbero essere validi anche dal lato client.
Invece di mappare i dati WCF su oggetti di dominio completi sul lato client, considerare la possibilità di associarli a oggetti di tipo ViewModel più semplici - una versione ridotta degli oggetti del dominio completo che contengono solo proprietà appropriate per il client - semplifica la programmazione dei client .

Il problema che stai ancora affrontando è un sacco di mappe. Immagino che valga la pena pagare questo prezzo (e reso più facile con uno strumento come AutoMapper ) perché la rimozione della dipendenza del client dal modello di dominio ti dà respirazione per cambiare il tuo dominio, modificare la mappatura, senza infrangere alcun codice client.