Nella mia organizzazione dobbiamo rispondere a un gruppo DBA separato per le decisioni come l'uso di LinqToSQL. Quali considerano alcuni dei migliori motivi per utilizzare L2S piuttosto che stored procedure.Gentile DBA: desidero utilizzare LinqToSQL anziché stored procedure perché
Penso che si riduca all'integrazione del codice. Piuttosto che dover guardare le stored procedure, puoi semplicemente guardare il codice nella tua applicazione.
Date un'occhiata a questo link ... http://www.linqpad.net/WhyLINQBeatsSQL.aspx
ho anche trovato la capacità di costruire SQL dinamico come query LINQ di non comparire in modo dinamico e piuttosto facile da mettere a punto. Ad esempio, supponi di avere una pagina di ricerca con 10 diversi criteri/filtri. Se l'utente ne limita solo 2, è possibile creare un metodo di estensione per aggiungere un filtro dove sulla query se alcune condizioni sono vere. Se avessi un sproc, avresti un sacco di confusione per eseguire il debug ...
Si sposterebbe la funzionalità precedentemente nel database nell'applicazione, che può essere una buona o una cattiva cosa. Penso che una buona argomentazione per LinqToSQL sia che può consentire di avere tempi di risposta più rapidi usando Linq se devi inviare la tua richiesta per le stored procedure al gruppo DBA, attendere che finiscano e poi lavorare con loro per prova e appianare eventuali problemi. È possibile utilizzare almeno Linq per l'accesso ai dati di base e quindi utilizzare le stored procedure se necessario (possono essere utili per alleviare i colli di bottiglia delle prestazioni).
Quando si utilizza L2S, più controllo è sotto lo sviluppatore dell'applicazione. Quindi, direi, puoi risolvere rapidamente qualcosa senza coinvolgere ulteriori comunicazioni con il gruppo DBA.
A parte i report che sono molto incentrati sui dati, raramente utilizzo la stored procedure al giorno d'oggi.
Leggi questo: "Why use Stored Procedures?".
La domanda Stackoverflow, Linq to SQL vs Stored Procedures?, ha alcuni punti positivi per entrambe le parti.
Utilizzando le stored procedure si ottiene un controllo più stretto sulle query e quando le prestazioni sono importanti questo può essere un vantaggio. È inoltre possibile apportare modifiche alle procedure senza la necessità di ricompilare e ridistribuire, il che può essere utile.
Tuttavia, utilizzando LINQ si ottiene la sicurezza del tipo, il DAL è più semplice da mantenere aggiornato e gestito insieme al progetto, è più facile testare e migliorare il supporto per il debug.
Concordato sulla sicurezza del tipo, questo è il più grande vantaggio per me. – bbqchickenrobot
Direi che LINQ to SQL NON è decisamente più facile da testare. Dato che ti offre molte più possibilità per la costruzione di query, hai molti più punti da testare di un semplice elenco di parametri per una stored procedure. –
Preverrà anche contro SQL Injection.
Sprocs fare troppo, ma gli amministratori di database saranno preoccupati per questo, se si utilizza linq2sql, in modo da far loro sapere che questo vi aiuterà nel convincente che ti permette di utilizzare L2S
L2S consentirà altresì ai DBA di concentrarsi su ottimizzazione del Database e delle sue strutture di tabella, indici, ecc. e non doversi preoccupare di supportare eventuali sprocs all'interno del database, poiché tale responsabilità verrà trasferita al team di sviluppo.
Entrambe le procedure e Linq2sql impediscono questo. Eventuali query paramterizzate impediranno questo. – bbqchickenrobot
@bbqchickenrobot: sei corretto, ma gli amministratori di database non possono utilizzare il fatto che sprocs impedisce l'iniezione di SQL come metodo per promuovere sprocs> linq2sql (credo che questo sia quello che stavo davvero cercando di dire) –
check this out, è stato una sorta di discusso qui:
LINQ-to-SQL vs stored procedures?
Inoltre, ci piace usare LINQ per la lettura dei dati e stored procedure per l'aggiornamento dei dati in quanto v'è un certo commercio logica nei nostri sproc (purtroppo). Non sono d'accordo con la logica biz in sprocs tuttavia con l'eccezione del più rudimentale. Ci possono essere argomenti per entrambe le parti e quelli sarebbero rilevanti per il tuo ambiente.
ci sono molti pro contro ogni modo, ma per decidere l'architettura dell'applicazione in modo da non dover guardare le stored procedure, è semplicemente pazzesco! –
@ KM: non pensare che abbia mai suggerito di usare LINQ per evitare di dover scrivere un sproc. Sono un fan del modello di responsabilità singola, quindi il più delle volte la mia connettività al database e il modo in cui ottengo i dati è una qualche forma di struttura stand alone ... Sono d'accordo che ci sono pro/contro in ogni modo e tu è necessario prendere una decisione su quale sarà la tua struttura DAO caso per caso. – RSolberg
@RSolberg ha dichiarato: "Penso che si riduca all'integrazione del codice, piuttosto che guardare le stored procedure, è sufficiente guardare il codice nella propria applicazione." Ho letto "Piuttosto che dover guardare le stored procedure" come se fosse "così non devi guardare le stored procedure". –