Approccio alla progettazione del software per un grande database relazionale

Entrambi gli approcci ti porteranno all'apprendimento, ma a competenze diverse.

Uno ti aiuterà a imparare le complessità di EF, l'altro ti permetterà di imparare meglio il tsql grezzo.

Considererei entrambi importanti. Quindi, non dovresti scegliere ciò che è meglio per questo caso particolare (EF) e impararlo?

C'è una conoscenza infinita che può essere acquisita, concentrare i tuoi sforzi sul più immediato beneficio.

will utilize a complex and large relational database

OR mapper come EF possono aiutarti a evitare il noioso lavoro con modelli "complessi". Devi scrivere meno codice, specialmente meno codice CRUD. D'altra parte, quando si gestisce un database "grande" (in termini di enormi quantità di dati relazionali, come hai scritto), devi fare attenzione che il mappatore OR non produca più problemi di quanti ne risolva. Per questo tipo di DB, in genere devi fare uso di SQL fine-tuned, elaborazione bulk SQL, stored procedure, ecc., Tutte cose in cui l'ORM non sarà utile.

E anche quando grande significa solo "molte tabelle e relazioni", EF potrebbe diventare un collo di bottiglia, vedi i collegamenti dietro questo post del forum:

link

Quei collegamenti SO potrebbero essere utili anche per te:

link

link

In termini di apprendimento:

Entrambi sono utili per la maggior parte delle carriere degli sviluppatori.

• Se utilizzi EF nel tuo progetto, otterrai esperienza che puoi utilizzare con altri ORM.
• Se non utilizzi EF in questo progetto, avrai più esperienza con l'SQL raw che ti servirà in seguito per altri database.

A seconda della tua carriera:

• EF sarebbe meglio se sapessi che probabilmente trascorrerai la maggior parte del tuo tempo in futuro a sviluppare applicazioni CRUD. Spesso beneficiano molto degli ORM, quindi molti si affidano agli ORM praticamente senza accesso diretto al database.

• Nessun EF sarebbe meglio se sapessi che gestirai applicazioni che non usano ORM perché hanno una struttura troppo inappropriata per ORM o perché usano un sacco di codice legacy o solo perché sono scritte in lingue in cui non esistono ORM di buona qualità.

Nota che se hai poca esperienza con l'attuale ingegneria del software, devi fare attenzione quando usi EF: assicurati di capire come il tuo codice è tradotto in query SQL da EF , e assicurati anche di comprendere le query stesse. Il modo migliore per farlo è attraverso l'ampio profiling SQL. Se vedi qualcosa che non ti aspetti, cerca e scopri perché il codice è stato tradotto in questo modo.

Seriamente, fallo. Un sacco di persone che iniziano a utilizzare gli ORM con poca o nessuna esperienza in SQL si trovano a scrivere codice terribile che non fa quello che si aspettano e quando, una volta sul server di produzione, si accorge che il loro codice esegue esattamente la stessa query diverse centinaia volte invece di uno, è troppo tardi troppo costoso da risolvere.

In termini di rendimento:

EF non è né lento né veloce. Se lo stai usando correttamente, la tua applicazione sarà abbastanza veloce. Se qualcosa è lento, usa il profiler per trovare dove è il collo di bottiglia, e se trovi che la lentezza è causata da EF, e non da come lo usi, allora fai una query diretta per risolvere questo collo di bottiglia.