luciusinfabula ha scritto:
chiedo consiglio ai più esperti di me.
Non sono più esperto, ma provo a portare lo stesso la mia esperienza.
luciusinfabula ha scritto:
Sono, con molta difficoltà, riuscito a capire a grandi linee Entity Framework dopo essermi fatto anche un corso online su Linq, le entità, migrazioni, etc, ma sto avendo ancora difficoltà ad effettuare query complesse con molte tabelle collegate con inner join, left join, etc. Faccio difficoltà a passare dal ragionamento stile Sql a quello di EF.
Recuperare dati con EF facendo join tra tabelle e arrivando a costruire anche una query complessa, in genere, non è una operazione che mi crea troppe problematiche, ma visto che parli di "molte tabelle collegate" credo che il problema risieda più nel fatto che, per determinate operazioni di interrogazione dei dati, sia preferibile ricorrere comunque ai classici strumenti che il DB mette a disposizione e a un implementazione basata sul classico e sempreverde SQL.
Mi spiego: le join di EF le utilizzo se voglio portare in un DTO i dati che provengono da una tabella, includendo anche altre tabelle nella correlazione, applicando dei filtri o degli ordinamenti dinamici, sfruttando le potenzialità di LINQ associato all'ORM stesso, ma se si tratta di generare dei prospetti complessi faccio comunque ricordo a viste e stored su SQL Server (il database che uso più di frequente).
Ad esempio, mi è capitato di dover recuperare informazioni sulle variazioni di stato di alcune entità e calcolare dei "delta temporali" su alcuni elementi limitando la selezione per stati particolari e condizioni specifiche di ciascuno, andando poi a generare un report: in casi come questo, credo che una classica stored procedure sia più adatta (al posto di codificare la stessa logica in EF) per assolvere il compito. Ciò che ho fatto sfruttando EF è invece la correlazione dei risultati ottenuti dalla SP con una tabella di decodifica, senza dover intaccare nuovamente la SP (almeno inizialmente), condizione che ho integrato poi sempre nella SP in un secondo momento.
Cosa voglio dire in soldoni? EF è un ottimo tool e grazie a LINQ consente di eseguire direttamente in C# le operazioni di correlazione dei dati costruendo anche scenari complessi, ma quando il codice diventa troppo complesso oppure le query troppo articolate e illeggibili, forse è il caso di utilizzare gli strumenti classici di interrogazione dei dati e lasciare a EF il compito unico di trasferire quelle informazioni in un DTO mappando direttamente i valori di ritorno della SP in oggetti e trasferendo in quelle strutture i dati acquisiti dalla procedura.
luciusinfabula ha scritto:
Avete da consigliarmi qualche buona fonte es. libro o corso youtube o qualche corso tipo Udemy per quanto riguarda la parte puramente di query che non siano le solite banalità dei semplici esempi che riportano i vari siti?
Non conosco libri o corsi particolari, ma sarebbe da chiarire qual è la problematica specifica che incontri quando lavori con EF.
O meglio, diciamo che il problema lo hai descritto, ma sarebbe da approfondire se si tratta di un problema legato al fatto che stai raggiungendo i limiti di EF nel gestire determinate operazioni che andrebbero trattate con altri tool più adeguati (vedi SP) oppure se fatichi anche nei casi più semplici a scrivere una query di base partendo da una istruzione SQL con operazioni di JOIN relativamente semplici. Magari qui si potrebbe esemplificare per capire meglio.
Ciao!