LINQ to SQL è morto?


17

C'è qualche motivo per continuare a utilizzare Linq to SQL o è meglio passare a tecniche ORM come EF, NHibernate ecc.

Stiamo usando Linq to SQL in una nuova grande applicazione aziendale che esisterà per molto tempo. La motivazione di questa nuova applicazione aziendale è che l'applicazione era ordinaria scritta in Visual Basic e poiché Microsoft ha interrotto il supporto dove siamo stati costretti a riscrivere l'applicazione. Sembra che siamo già lì, ma questa volta con il nostro DAL (Data Access Layer).

Ho già letto questo articolo , ma si confronta solo con la debolezza di EF.


+1 fantastico Q. Questo è affascinante per me, ho pensato di spostare le mie procedure memorizzate e le stringhe di query SQL parametrizzate su LINQ to SQL per una migliore leggibilità, non avevo idea che non fosse più sviluppato.
fearoffours,

MS ha un piccolo tipo di presentazione di .NET 4 che dice che non è morto, ma ciò può significare molte cose. Lo hanno migliorato in .NET 4.0: damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40
MetalMikester

Non di nuovo. Questa domanda è stata discussa fino alla nausea su StackOverflow. Sai dire FUD?
Robert Harvey,

Risposte:


11

Se lo stai già utilizzando e non stai riscontrando alcuna difficoltà, mi atterrerei su progetti esistenti.

Linq2SQL è un ORM piuttosto carino, ma limitato: se vuoi mappare i tuoi oggetti in modi più complessi rispetto a quelli di base forniti da Linq2SQL, rimarrai bloccato. Microsoft ha risolto alcuni bug quando è uscito con .net 4, ma ha dichiarato che non dedicherà risorse per estenderlo.

Direi che se hai un progetto abbastanza semplice che probabilmente ha una durata limitata, allora Linq2SQL è una scelta leggera decente fintanto che stai attento a non perdere dipendenze da Linq2SQL dappertutto. Per qualcosa di più andrei con qualcos'altro (NHibernate o EF per esempio) poiché Linq2SQL è praticamente un vicolo cieco.


Posso solo essere d'accordo, non proprio morto, ma è in qualche modo sul tavolo nel triage. Se le cose stanno funzionando ed è un grande impatto cambiarle ora ... beh potresti voler rilassarti un po 'e cercare un buon momento per mettere la conversione in EF / NHibernate, potrebbe essere un progetto di aggiornamento finanziato (alla fine noi tutti vogliono un lavoro, pane e burro sul tavolo).
cyberzato il

@cyberzed: sembra una buona scusa per un lavoro inutile.
Robert Harvey,

12

Non è morto, ma Microsoft è ora focalizzato su Entity Framework.

Ho usato LINQ to SQL su piccoli progetti ed è abbastanza bello come un livello dati leggero e prenderei in considerazione di usarlo di nuovo su progetti di dimensioni simili. L'implementazione LINQ stessa è davvero buona e fino a poco tempo fa molto meglio del progetto NHibernate LINQ. Nel progetto più ampio su cui ho usato L2S, ho trovato difficile elaborare uno schema di unità di lavoro di cui ero soddisfatto, a causa delle limitazioni della classe 'DataContext' di L2S. Cercare di implementare qualcosa come "Sessione per richiesta" con L2S sembra molto difficile o impossibile.

Inoltre, non considererei davvero L2S come un vero ORM, in quanto non offre molte opzioni di mappatura. Il design della tua classe deve davvero seguire lo schema del tuo database (tabella per classe), altrimenti combatterà con te in ogni fase del processo. Un'altra cosa che non mi piace di L2S è la necessità di utilizzare tipi specifici ( EntitySete EntityRef) per gestire raccolte, riferimenti e caricamento lento. Ciò significa che non è possibile mantenere il tuo modello di dominio ORM agnostico senza aggiungere un altro livello di astrazione.

L'altro mio problema con L2S è la sola dipendenza da LINQ per generare query. Il provider LINQ è scritto molto bene e generalmente crea un SQL decente per la maggior parte delle query, ma temo che ci siano query più complesse che non possono essere espresse bene con LINQ. Utilizzando L2S, in questi casi è necessario ripristinare le chiamate alle procedure memorizzate, mentre (ad esempio) NHibernate ha diverse API (provider LINQ, QueryOver, HQL ecc.) Che possono essere utilizzate quando si desidera un maggiore controllo sull'SQL generato.

Nella difesa di L2S su NHibernate, c'è molto meno sovraccarico nel metterlo in funzione e funzionare su un progetto.


2

Non è morto perché funziona ancora, ma se non viene sviluppato ulteriormente, può avere senso passare a qualcos'altro.

Tuttavia, se funziona per la tua applicazione non ha senso cambiare per motivi di cambiamento.


2

più stabile di un morto:

http://www.thinqlinq.com/default/LINQ-to-SQL-enhancements-for-2010.aspx

http://jonkruger.com/blog/2009/06/06/linq-to-sql-is-not-dead/

Hanno spostato i loro sforzi di miglioramento su Entity Framework dove è davvero necessario se quel prodotto ha successo. Non aspettarti nulla di nuovo ma compatibilità e correzione dei bug su linq2sql per un po '.

Questo sito è gestito con un sacco di linq2sql se non sbaglio.


+1 per "stabile" Il modo migliore per visualizzare L2S, imho. Stabile e non essere più esteso / modificato.
Quentin-starin,

Ci dispiace ma "niente di nuovo ma compatibilità e correzione di bug" significa che è nel contenimento. Questa è fondamentalmente una garanzia che la comunità si allontanerà da essa, non vedrai molti nuovi progetti utilizzarla e quindi probabilmente non vorrai nemmeno usarla in nuovi progetti. "Dead" non significa che non funziona, significa solo che c'è poca innovazione o interesse.
Jeremy,

Dal punto di vista di una grande impresa, il fatto che il core non venga più modificato significa che può finalmente andare sulla lista delle tecniche approvate in molti casi. Nella mia linea di lavoro lo stiamo aspettando da tempo. L'EF è ancora troppo instabile per saltare e L2S attirerà sempre l'interesse per le situazioni in cui non si desidera il sovraccarico dell'EF.
Bill,

@Jeremy Le persone usano ancora TeX?
alternativa

1

È strano ma ho visto molto questo fraseggio ("LINQ2SQL è morto") e non sono sicuro da dove provenga *. È altrettanto morto Windows XP. Microsoft ha interrotto il supporto e ha creato qualcosa di nuovo (e ai miei occhi meglio) eppure le persone sono ancora libere di usare XP così come sono libere di usare Linq2SQL. Devo ammettere che utilizzo Linq2SQL durante la creazione di moduli DotNetNuke personalizzati. Tuttavia, con nuove funzionalità in EF4 come code-first-development ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx ) è difficile trovare motivi per rimanere fedeli a Linq2SQL. Non vedo un motivo per passare in rassegna e aggiornare il codice ma per il nuovo codice non so perché non vorresti usare EF4.

* In tutta onestà, sono molto ... ossessivo per la semantica! Mi scuso se è fastidioso per gli altri :)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.