Perché tutte le entità Linq To odiano?[Chiuso]

Question

Ho notato che sembra esserci un po' di ostilità nei confronti di Linq To Entities, in particolare da parte della gente di Alt.Net.Comprendo la resistenza a una maggiore programmazione "trascina e rilascia", ma da quanto ho capito, Linq To Entities non lo richiede.

Attualmente stiamo utilizzando Linq to SQL e stiamo utilizzando il documento DBML per definirlo (una volta ottenute più di una dozzina di tabelle, il designer è piuttosto inutile).

Allora perché lo stesso approccio non dovrebbe funzionare per Linq To Entities?

Answer 1

Non penso che sia un odio per il idea di esso di per sé.È solo che alla gente non piace implementazione di esso.

http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Answer 2

In realtà, una volta che inizi ad approfondire, LTE è completamente inutile per i framework di livello aziendale.Il fatto che ci sia pochissimo supporto per l'ereditarietà (anche in LTS) rende molto codice ridondante.Inoltre, tornerò a LTS (Linq to SQL) perché in realtà consente di definire mappature tramite attributi anziché un file.LTE funziona solo con un file esterno.

Answer 3

L'odio per Linq to Entity è ampiamente meritato.Questo prodotto non riesce a raggiungere alcuno scopo più complesso delle noiose demo per cui GU lo utilizza sul suo blog.EF è lungi dall'essere pronto per il debutto.Microsoft semplicemente non riesce a ottenere dati corretti nel mondo .BLOAT, sembra che cambi il paradigma dei dati ogni volta che soffia il vento.FoxPro esiste da 20 anni con lo stesso nucleo dati di base.Dato che SQL Server utilizza gran parte della tecnologia dei dati VFP, forse MSFT potrebbe imparare qualcosa sulla manipolazione dei dati e sui linguaggi incentrati sui dati da qualcosa che ha funzionato.

Answer 4

Sono abbastanza convinto dei principi di Linq to Entities e dell'Entity Framework in generale, ma ho delle riserve sulla sua attuale incarnazione.Ammetto però liberamente di non averlo usato in niente di più che in modo autodidattico e molto piccolo.Il livello di flessibilità non sembra essere ancora arrivato, ma sono sicuro che arriverà.Uno dei sostenitori della tecnologia per la SM (ottimo titolo professionale) mi ha detto che EF era la scelta strategica per la SM per il futuro.Supponendo che sia così, posso solo vedere che le cose miglioreranno in questo campo.

Answer 5

Potrebbe esserci anche un po' di animosità da "secondo posto".La SM lo è molto tardi per commercializzare L2E, io stesso mi sono interessato all'ORM circa tre anni fa o giù di lì e la MS non si vedeva da nessuna parte a questo punto.

Molti di noi hanno già trascorso del tempo imparando un altro ORM (come NHibernate) e sono abituati a un certo livello e tipo di funzionalità disponibili e questo non è ancora evidente in L2E.

Questa animosità da "secondo posto" non è una vecchia notizia, a dire il vero, non so perché MS non dedica più tempo a supportare soluzioni già in atto, abbiamo già visto tutto questo con NAnt -> MSBuild e NUnit -> MsTest , farebbe risparmiare a tutti un sacco di tempo e fatica se accettassero semplicemente una delle soluzioni migliori e mature e si sforzassero di supportarla invece di crearne sempre una propria.

Answer 6

Vorrei aggiungere che l'implementazione LTE dell'ereditarietà TPT è a dir poco criminale.Vedi la mia domanda Qui.

E già che ci sono, credo che molti esperti EF pubblicati sono almeno in parte complici.Devo ancora trovare materiale pubblicato su EF che metta in guardia contro le query sui tipi di base.Se dovessi provarlo sul modello che ho, SQL Server si arrende semplicemente con l'eccezione.

Una parte della tua dichiarazione SQL è nidificata troppo in profondità.Riscrivi la query o romperla in domande più piccole.

Mi piacerebbe riscrivere la query, ma LTE mi ha assolto da questo peso.Grazie (^no)