Cattiva pratica utilizzando Classi generate automaticamente per l'accesso ai dati

Question

Cattiva pratica utilizzando Classi generate automaticamente per l'accesso ai dati

#1 da (3 voti)
#2 da (-1 voti)
#3 da (-2 voti)

2

L'ho visto prima, ma non ho trovato ragioni concrete.

Quando aggiungi Entità al tuo modello EF, EF auto genera le classi per queste entità.

In termini di DataAccess, perché è preferibile non utilizzare queste classi generate automaticamente e invece utilizzare i propri modelli di dati per l'accesso ai dati.

Ex.

 EFAutoGeneratedClass = //query = BAD 

 SeparateModelClass = //query = Good

object-oriented design c# entity-framework

posta CSharper 24.11.2014 - 18:34

fonte

3 risposte

Leggi altre domande sui tag object-oriented design c# entity-framework

Gestione dell'autenticazione di accesso / Sessione di pagina Web: il lato client javascript / JQuery può accedere a una variabile di sessione oa una variabile json in html? Architettura del server di videoconferenza

score 3 · Answer 1

Un database, essendo i dati e generalmente ottimizzato per l'efficienza e il recupero dello storage, non si collega necessariamente direttamente alle classi dei domini aziendali. Quanto meno una classe generata automaticamente si adatta a un modello di dominio appropriato, tanto maggiori sono i problemi di manutenzione del codice.

Il design del database sta ora guidando la progettazione del dominio.
Un modello di dominio dovrebbe modellare il tuo dominio, non il tuo database.
Come diavolo si disfa da un data store se il dominio è l'archivio dati?
Codice aggiuntivo per far funzionare le classi DB con classi di dominio appropriate.
Il buon design tende a essere limitato perché ... "clic" - guarda! classi istantanee e il loro codice CRUD [1]. Design completato.
Se insisti a garantire una conservazione corretta e coerente dei dati degli oggetti di dominio, devi comunque scrivere il codice CRUD per integrare le classi istantanee.
Rational potrebbe essere: "Leggiamo tutti i dati ora - evita di usare l'I / O di Sloooow". Questo vecchio, originale, spunto su .NET "working disconnected" è @ (# * $ & amp ;; rende molto lenta la risposta all'interfaccia utente.
Nell'analisi finale il database è solo un dettaglio di implementazione.

[1]: C reate R ead U pdate D elete

score -1 · Answer 2

Se il database cambia, le entità generate automaticamente cambieranno dopo l'aggiornamento del suo schema. Non vuoi che queste modifiche infrangano il tuo codice, ma se dipendi da esse, potrebbe violare il tuo codice (in molti posti in opposizione a un posto se trasferisci il contenuto dell'entità sul tuo modello)

score -2 · Answer 3

Il mio problema con il codice generato automaticamente è la mancanza di manutenibilità. Se c'è una piccola modifica nel database, devi aggiornare l'intera sezione di codice generato e assicurarti che siano entrati solo i cambiamenti previsti. E se non stai usando alcun repository di codice che non ti dice le modifiche nel codice quindi è molto più difficile trovare le modifiche al codice. Significa anche che l'intero componente deve essere testato di nuovo completamente per tutti gli scenari.

Inoltre, ho notato che gli sviluppatori che lavorano sul codice generato legacy a volte apportano modifiche manuali nel codice generato invece di generare nuovamente la sezione del codice generato automaticamente. Dopo un periodo di tempo diventa quasi impossibile sostituire il codice generato automaticamente.

Il Code First of Entity Framework mi sembra un'opzione molto migliore. La modifica del codice è localizzata in un determinato file, quindi meno possibilità di rompere qualsiasi funzionalità esistente.

Quindi, in poche parole, se hai un team molto disciplinato che non tocca le sezioni generate e copre anche diligentemente tutti gli scenari di test usando Test unitari ... quindi con tutti i mezzi puoi adottare un approccio al codice generato ma provare ad avere Codice Primo approccio il più possibile.