Quali sono i pro e i contro dell'esposizione diretta di una tabella / classe di entità View al client?

Diciamo che abbiamo una tabella di utenti che memorizza:

1. Id,
2. Nome,
3. Cognome,
4. E-mail,
5. Indirizzo,
6. Città,
7. Telefono e
8. mobile

Supponiamo che il nostro cliente abbia bisogno delle seguenti informazioni, in punti separati:

1. Nome utente,
2. Nome utente ed email,
3. Indirizzo postale dell'utente e
4. Numero di telefono dell'utente

Possiamo ovviamente sviluppare un insieme di funzioni (nel livello di servizio) come:

• getUserName (id), che restituisce il nome e il cognome,
• getUserNameAndEmail (id), che restituisce il nome e il cognome, più email,
• getUserPostalAddress (id) ... e
• getUserPhone (id) ...

o potremmo sviluppare solo una funzione:

• getUserInformation (id), che restituirebbe tutte le informazioni dell'utente indipendentemente da dove è necessario dove.

Non c'è nessuna ragione tecnica ovvia per scegliere un metodo rispetto all'altro poiché entrambi hanno meriti chiari: il primo, trasferiamo solo i dati di cui abbiamo bisogno da un server all'altro, ma nel secondo modo creiamo solo una funzione e riutilizzalo ogni volta che abbiamo bisogno di informazioni sull'utente.

È una questione di dati volume e larghezza di banda. Se il client e il server sono collegati via Internet, e i nostri dati sono grandi, probabilmente dovremmo scegliere il primo metodo, in quanto non vogliamo che il cliente subisca ritardi non necessari. Ma se il client e il server si trovano su una rete locale o su una rete ad alta velocità, il secondo metodo è probabilmente il modo migliore per andare, dato che guadagniamo un po 'di tempo per lo sviluppo.

Ovviamente i nostri dati possono essere estremamente grandi e il primo metodo è preferibile anche su una rete locale, quindi per capire chiaramente perché il tuo team di sviluppo ha scelto le loro pratiche devi prima capire i dati con cui hai a che fare. Trovare (chiedere) alcune metriche concrete sarebbe un buon primo passo. Molto probabilmente scoprirai che i tuoi grassi dati risolvono più problemi di quelli creati.

I professionisti di esporre le entità direttamente a un cliente

• Poco overhead nella traduzione tra la struttura rdbms e la struttura dell'entità e quindi la soluzione lightweigth
• Fornisce un'interfaccia complessa che è utile per il throughput / efficienza della rete
• Facile serializzazione delle strutture dati
• Fornisce un mezzo di concorrenza ottimistica (offload il controllo e il blocco della concorrenza del database)
• Abilita il caricamento in cache degli elementi per l'efficienza (almeno utilizzando EF dbcontext)

Con di

• Quando i valori persistono, non c'è modo di verificare le istanze hanno superato la convalida prima di essere inviati per la persistenza
• Poco guadagnato esponendo le entità invece di utilizzare una connessione al database dal tuo client (ad esempio per gestire la concorrenza)
• Ci possono essere più di una versione del tuo cliente là fuori così le regole aziendali possono variare a seconda del tipo di coulod che crea problemi per il tuo schema del database
• cambiare il monitoraggio e la risoluzione dei conflitti richiederà uno sforzo maggiore rispetto all'utilizzo di un'opzione più granulare (modifiche basate sul campo)

Saluti, Carlo

Questo sarebbe molto soggettivo, ma di seguito alcuni punti da considerare.

• I dati hanno una struttura particolare. Nel tipico RDBMS questa struttura è relazionale.
• Una struttura dati dovrebbe essere scelta in base al tipo di operazioni / processioni che la logica dell'applicazione deve eseguire sui dati.
• Se c'è differenza tra la struttura dei dati del motore di elaborazione della tua applicazione e la struttura dei dati utilizzata dal tuo livello di persistenza, allora avrai bisogno di un livello intermedio (servizio o qualsiasi altra cosa tu voglia chiamare) che agirà come la struttura dei dati strato di trasformazione. Questo livello non dovrebbe fare nient'altro che questa mappatura tra la struttura dei dati.

Nel tuo caso particolare hai bisogno di porre la domanda, le 2 strutture dati differiscono in modo significativo, se sì, hai bisogno di quel livello di servizio, altrimenti non lo fai.

Se i client richiedono molti diversi raggruppamenti di dati e se non si dà loro la possibilità di richiedere i dati che desiderano attraverso un certo tipo di linguaggio di query, la costruzione di classi per restituire varie combinazioni di dati sarà una battaglia senza fine. Per ogni entità il numero possibile di combinazioni può essere assolutamente enorme se il numero di campi è superiore a pochi.

Quindi, se le classi create servono solo a limitare la quantità di dati restituiti, il lavoro probabilmente non ne varrebbe la pena. A meno che non ci siano raggruppamenti di dati molto comuni che vengono richiesti spesso da molti client diversi.

Ora, se si desidera limitare semplicemente la quantità di dati restituiti, è possibile creare classi che caricano lentamente i campi quando vengono richiesti. A seconda dell'architettura questo potrebbe essere utile. Ma in molti casi il caricamento lento danneggia in realtà la scalabilità e le prestazioni complessive.