È meglio creare una stored procedure o entità per ottenere i dati di cui ho bisogno?

Question

È meglio creare una stored procedure o entità per ottenere i dati di cui ho bisogno?

#1 da (5 voti)
#2 da (2 voti)

4

Sono appena entrato in un nuovo progetto con una nuova società utilizzando Entity Framework e ASP.NET MVC 4. Non sono un esperto di Entity Framework, ma penso di avere una conoscenza decente di come usarlo.

Da quello che posso dire, i miei modelli dovrebbero riflettere una tabella nel database omettendo le colonne di cui non ho bisogno. Inoltre, possiamo utilizzare stored procedure con Entity Framework o un IoC per mappare il modello.

Ho bisogno di connettere la relazione con due oggetti, la cui relazione è abbastanza nidificata. Potrei creare una procedura memorizzata per fare questo o creare una serie di modelli (basati sulle tabelle nel database) e utilizzare una configurazione IoC per avere una tabella dal database per ogni modello, quindi interrogare i modelli nel livello repository per dati ho bisogno di usare Linq alle Entità. Sembra che avrei un sacco di ".Include (x = > x.SomeModel)"

La mia domanda è: quale opzione è migliore per la manutenzione e l'integrazione nel futuro del progetto? Una procedura memorizzata o Linq alle entità?

O non sto capendo correttamente Entity Framework?

web-development entity-framework linq

posta Rayshawn 20.01.2013 - 23:51

fonte

2 risposte

2

Suggerirei di creare una vista e creare un'entità specifica associata a quella vista.

Tecnicamente non hai nemmeno bisogno di creare la vista nel DB, puoi modella la query esclusivamente nel modello di archiviazione EDMX , ma è un po 'più avanzato (ad esempio non supportato nella GUI). Detto questo, se si ha la possibilità di creare la vista nel DB, lo consiglio vivamente in quanto è possibile fornire più ottimizzazioni alla vista a livello SQL, se necessario (ad esempio indici specifici per la vista, ecc.).

risposta data 21.01.2013 - 00:29

fonte

Leggi altre domande sui tag web-development entity-framework linq

Entrare in Guava Strategia per sito Web con stringhe internazionali

score 5 · Accepted Answer

Penso che tu abbia definitivamente il succo di EF, questa è una buona domanda.

Ti consiglierei di andare sull'opzione Linq to Entities. Non aver paura di usare .Include (x = > x.a), e ricorda che poiché questo si unisce a un altro tavolo, dovrai assicurarti che i tuoi join (chiavi esterne) abbiano indici su di essi. Per me il vantaggio di mantenimento del framework entità è essere in grado di modificare la struttura della tabella (aggiungere / spostare / rinominare colonne) e quindi essere in grado di ricompilare il codice c # e raccogliere ciò che è rotto - man, questo mi avrebbe salvato DAYS di aggiustando i proc memorizzati qualche anno fa dopo aver apportato modifiche al DB. Se la tua logica è all'interno di un processo memorizzato, non ottieni questo vantaggio.

Solo se il tuo c # sta iniziando a diventare troppo complicato da mantenere, potresti considerare l'utilizzo di un proc memorizzato per eseguire il lavoro, il che potrebbe essere migliore per gli scopi di manutenzione. Oppure se stai interrogando un database che non può essere efficacemente utilizzato dal framework di entità (composto da chiavi esterne o altro).