Entity Framework con un grande progetto

Question

Io e il mio team avvieremo un nuovo progetto e siamo nella fase di esplorare e testare alcune nuove (o non così nuove) tecnologie.

Fino ad oggi usavamo l'ADO classico con DBDataReader, i proxy per il caricamento lento e in alcuni casi DataTable.

Il team è composto da 3 sviluppatori e un designer di database. I nostri progetti sono composti da almeno 130 tavoli ciascuno.

Il nostro nuovo progetto ha il potenziale per crescere quindi ci aspettiamo sicuramente 100 tavoli.

Ho letto e fatto alcuni semplici test con EF5 negli ultimi 2 giorni e non riesco ancora a decidere se dovremmo usarlo.

1. Di solito dividiamo un grande progetto in molti progetti "modulo" permettendoci di lavorare più velocemente e meglio sotto il controllo del codice sorgente. Utilizzeremo un grande "edmx" per l'intero DB?
2. Dal momento che abbiamo un Database Designer, sospetto che CodeFirst non sia un'opzione. Quindi vale la pena utilizzare EF con l'approccio Database First?
3. Se usiamo il primo approccio del Database, l'EF è abbastanza intelligente da rilevare tutte le relazioni correttamente ed essere pronto per l'uso senza ulteriori configurazioni aggiuntive da parte mia? (Per configurazioni extra voglio dire che dovrò scrivere DataAnnotations o dover ovveride DbContext)
4. Personalmente mi trovo molto sicuro della progettazione di un Database con sql. L'unico fastidio che ho è quando devo aggiornare tutti i select, delete, update, insert scripts quando un'entità viene cambiata nelle mie classi-Lists. EF si prenderà cura questo per me, ma tranne questo sto iniziando a credere che rallenterà le prestazioni e finirà per rallentare la mia produzione dal momento che non ci sono familiari con esso ..

Cosa pensi sia LO VALE?

* A parte le informazioni DataAnnotation e DbContext ovveride, c'è qualcuno che utilizza modelli T4 semplici per creare le tabelle (schema)?

Answer 1

Ho deciso di non utilizzare l'EF. Non ho intenzione di correre il rischio di usarlo in un grande progetto.

Tutto il lavoro necessario per usarlo, la possibilità di trattare con gli insetti, il sovraccarico .. Io preferisco scrivere più di codice SQL e trascorrere più tempo mantenendo, che fare con i modelli generati o di controllo della profiler SQL per la query generate ..

Grazie a tutti per i vostri commenti ..

* prima di andare a ADO dritto di nuovo darò un colpo di FluentData e Dapper .. aprirò una nuova domanda quindi se voi ragazzi voglio commentare questi due ORM leggeri, posterò il link più tardi.

Answer 2

Se la struttura del database è matura, EF dovrebbe essere una buona soluzione per voi.

Se la struttura del database è in fase di sviluppo, o cambierà molto nel tempo, direi che EF potrebbe non essere il migliore per te.

EF deve essere aggiornato quando sono presenti modifiche strutturali (e potenzialmente modifiche di interfaccia a livello di database). Dovresti considerare come gestirai le modifiche al database all'interno del tuo codice base già sviluppato.

Answer 3

1. Consiglio vivamente di creare più modelli. È possibile selezionare le tabelle, le viste e le stored procedure da mappare per ciascuna.
2. Il primo database è assolutamente valido.
3. Se i vincoli del database sono stati impostati, EF li riconoscerà. Non farai piccole modifiche, ma tutto sommato EF fa un buon lavoro.
4. L'utilizzo di EF avrà un leggero impatto sulle prestazioni della query. Ma nella maggior parte dei casi questo non sarà un problema. Nei pochi casi in cui si può avere un impatto sulle prestazioni inaccettabile, è possibile ottimizzare iniettando il proprio SQL in EF, se necessario.

Penso che acquisirai familiarità con l'utilizzo di EF abbastanza rapidamente, quindi non penso che la non familiarità sarà un problema a lungo.