Entity Framework significa che potresti non dover mai utilizzare SQL o progettare nuovamente le tabelle del database?
Questo è ciò che significa "ignoranza della persistenza"?
Sono nuovo di EF e ORM in generale, e mi piacerebbe capire quanto di esso sia hype e quanto sia la realtà.
EntityFramework è un ottimo strumento, ma come ogni grande strumento ti farebbe un grosso disservizio per non capire il funzionamento interno di come traduce un modello di dati in uno schema di database, e anche come traduce le sue query in SQL.
Tutto funziona alla grande fino a quando qualcosa va storto, quindi stai cercando nei file di log cercando di decifrare l'SQL generato per capire dove si trova il bug. Buona fortuna se non hai una comprensione dello schema o SQL.
Il termine "Persistenza Ignoranza" è indicato come una buona cosa, ma solo in termini di creazione di un accoppiamento lento dal tuo livello di accesso ai dati. La tua logica di business e i livelli di presentazione dovrebbero essere "Persistenza Ignorante", non lo sviluppatore!
Solo negli Stati Uniti l'Ignoranza viene celebrata come una buona cosa;)
In realtà no. Verranno applicati i concetti di base del database e dovrai conoscere alcune regole di base su cosa possono fare i database o altrimenti dovresti affrontare problemi di prestazioni significativi.
Entity Frameworks è utile per gestire la conversione dei dati di mappatura dai record del database in oggetti. Ciò consente agli sviluppatori di non dover gestire la creazione di oggetti di accesso ai dati poiché il framework lo fa già per te.
Quindi questo farà un bel po 'per gli sviluppatori, specialmente quando persistono i dati.
La ricerca dei dati può essere eseguita anche con framework di entità, ma le ricerche non sempre vengono eseguite al meglio solo con i framework di entità, perché se eseguite in modo errato si avranno problemi di memoria quando qualcuno decide di caricare l'intero database in memoria. O problemi di I / O se qualcuno decide di eseguire query all'interno di un'altra query. (Questi due sono i problemi di prestazioni comuni che vedo quando rivedo il codice di altre persone).
A volte potrebbe essere necessario disporre di SQL raw, stored procedure o vista del database per ottenere il miglior rapporto prestazioni / manutenibilità.
Poiché un buon DBA è una risorsa preziosa. Sebbene io tenti di relegare il database in modo che sia solo un archivio dati, è comunque necessario eseguire l'ottimizzazione in modo che gli indici e l'allocazione di archiviazione corretti siano eseguiti correttamente.
Una cosa che i framework di entità mi permettono di fare è parlare di oggetti e tabelle con il DBA in termini logici piuttosto che in termini fisici. Permette lo sviluppo di applicazioni e il database per formare un contratto sotto forma di un diagramma relazionale di oggetti che accettano di ridurre le possibilità di difetti (o per lo meno assegnare rapidamente la colpa).
UPDATE: Altre tre cose che vorrei aggiungere ...
Views. Gli ORM possono essere in grado di leggere le viste, ma richiede un DBA relativamente avanzato per renderne uno molto complesso, in modo da ottimizzare le query per altre parti dell'applicazione.
Migrazione dei dati. man mano che il tuo progetto cresce, lo schema sarà tuo. Avresti bisogno di un DBA abbastanza esperto per sapere come migrare i tuoi dati da una versione dell'applicazione a un'altra.
Archiviazione dei dati. mano a mano che il progetto continua, alla fine avresti un set di dati di grandi dimensioni e dovresti capire come partizionare e archiviare i vecchi dati così sarà non ha impatto sulle prestazioni.
+1 a maple_shaft. Vorrei aggiungere che anche quando stai usando il codice EF (molto balyhooed), stai ancora modellando le tabelle. Sono passati più di 20 anni che le persone hanno utilizzato strumenti di modellazione e CASE che mettono uno strato di astrazione tra loro e lo script DDL che costruisce le loro tabelle. Ciò non cambia il fatto che hanno bisogno di sapere come progettare correttamente le tabelle.
Sicuramente no perché EF dipende strongmente dalla corretta progettazione del database. Di solito non ci si aspetta l'aspettativa se usato con database legacy o progettati in modo errato. Anche la piena potenza di EF può essere scatenata solo quando si combina con SQL diretto.
Ogni astrazione ti protegge da alcune implementazioni. ORM è l'astrazione dell'accesso ai dati, ma solo le scimmie di codifica sono schermate da questi dettagli. Gli sviluppatori devono comprendere i concetti che corrono sotto la cappa dell'astrazione per sapere come usarli correttamente.
Leggi altre domande sui tag entity-framework persistence