Würden Sie LINQ verwenden für neue Projekte SQL?

Question

Ich habe untersucht, welche Datenschicht für ein neues Web-basiertes Projekt verwenden Ich bin die Gestaltung und ich bin sehr daran interessiert, LINQ to SQL betrachten enthält. Seine scheinbare Einfachheit, Flexibilität und Designer-Unterstützung wirklich Appelle und die implizite Tie-in zu SQL Server ist in Ordnung.

Es hat sich aber erst vor kurzem bekannt gegeben, dass LINQ to SQL wird nun ein Rücksitz in die Entity Framework nehmen, dass es an die ADO.NET-Team übergeben worden ist ( http://blogs.msdn.com/ adonet / Archiv / 2008/10/29 / update-on-Linq-to-sQL-and-Linq-zu-Entitäten-roadmap.aspx ). Sicher, es wird in Zukunft unterstützt werden, aber es ist unwahrscheinlich, dass es viel mehr Entwicklungsarbeit sehen.

diese mit im Auge, würden Sie mir empfehlen, diese Technologie für mein Projekt mit oder lohnt es sich, entweder einen alternativen ORM Auswahl (nHibernate?) Oder manuell eine generische DAL Codierung auf?

Das Projekt selbst ist ASP.NET und SQL Server 2005/2008 basieren und möglicherweise MVC verwenden, obwohl es in der Beta noch ist. Es ist ein persönliches Projekt, wird die Datenbank nicht zu komplex sein und es wird vor allem als Prototyp verwendet werden, um .NET Zukunft Tech zu suchen. Ich würde auf zukünftige Projekte werden zu stützen, was ich von diesem lernen aber, so dass die Entscheidungen, die ich werden größere Lösungen beeinflussen machen kommen.

Und ja, ich merke, dass Microsoft wird wahrscheinlich sowieso eine ganz neue Datenzugriffstechnologie von morgen bringen! ;)

Answer 1

Nun, es ist vor allem in den Antworten hier (einige interessante Gesichtspunkte als auch) bereits abgedeckt, aber ich werde es noch einmal sagen sowieso ..

LINQ to SQL (L2S) ist sehr vielseitig, aber es fühlt sich ein bisschen zu einfach aus meiner Sicht. In den meisten Fällen hat es einen guten Job bei einfachen Dinge zu tun, aber sobald Sie ein wenig mehr davon fragen, wird es teuer. Dies ist nicht eine schlechte Sache. Ich glaube tatsächlich, LINQ to SQL tatsächlich das Entity Framework suppliments schön.

Nehmen Sie Auto Paging mit LinqDataSource zum Beispiel. Wenn Sie nicht sortieren / Gruppe angeben Bis dahin ist es recht sparsam. Werfen Sie die Bestellung oder die Gruppierung in die Mischung und starten Sie eine Spitze in der Leistung zu erhalten (wird sehr gesprächig). Sie haben dann ziemlich Ihre eigene Auslagerungs Implementierung schreiben (was nicht sehr schwer ist, lasse ich zu).

Ich werde die erste zugeben, dass L2S den Vorteil gegenüber dem Entity Framework in Bezug auf die Qualität des erzeugten T-SQL hat (ich sollte, da L2S speziell für die Abfrage von SQL Server erstellt wird) und konzeptionell und symantically, viel von LINQ to SQL ist zu EF ähnlich, aber wo man gegen die Wand ist auf Bedürfnisse und Rücksicht auf kompliziertere Implementierungsanforderungen erweitert.

Wenn ich von Grund auf neu beginnen waren, und wählen Sie die persönliche Entwicklung Zeit zu widmen, würde ich das Entity Framework holen. Interessanterweise arbeite ich an einem Projekt zur Zeit der L2S verwendet und es entworfen wird nad Griff schwere Lasten zu skalieren, aber wenn wir einige der „kreativen“ Anforderungen getroffen werden wir oft auf SQL Metal zu erweitern gezwungen (zB many-to-many-Beziehungen).

Also .. kurz gesagt .. Ich würde es Ansatz so:

a) lernen LINQ als Intro to SQL (Microsofts ORM Muster und Technologie) .. es wird man mit den meisten der Grundlagen vertraut, die mit dem Entity Framework und einen Geschmack von LINQ Stil anfragende (ein erworbener Geschmack geteilt werden wenn Sie einen Hintergrund in T-SQL)

b), wenn Sie einen Griff auf LINQ to SQL habe, würde ich einen Sprung über zu dem Entity Framework empfehlen die zusätzlichen Vorteile (eSQL usw.)

lernen Implementieren Sie

c) ein Proof of Concept-Projekt in beide und vergleichen Sie die Ergebnisse.

Answer 2

Pick NHibernate. Es wird noch einige Zeit als ein Konzept oder den tatsächlichen ORM bleibt um. So wird es nützlich sein, sowohl zu lernen.

Answer 3

IMO, diese ganze Sache war wirklich in keinem Verhältnis geblasen.

Microsoft habe nicht gesagt, dass LINQ to SQL tot sein würde. Sie mehr darauf hin, dass es in Entity Framework verschmolzen würde.

Ich würde den Schwerpunkt auf die als Lösung Entity Framework verwenden, zu wissen, dass ein großer Teil der LINQ to SQL wird in sie gerollt werden.

Es ist wirklich nicht so viel Unterschied im Augenblick sowieso. Die größte Beschwerde ist, dass das Entity Framework ist nicht leicht. Ist das wirklich egal, solange Sie eine gute Trennung zwischen den Ebenen haben?

Answer 4

L2S ist, meiner Meinung nach, völlig in Ordnung, so wie es ist und wie Sie gesagt haben, ist nicht überall. Die Firma für die ich arbeite ist es unseren Standard für den Datenzugriff gemacht und wir verwenden es für alles von kleiner 5 user Nische apps Benutzer Enterprise-Anwendungen mit sehr guten Ergebnissen 1000+.

Answer 5

Überprüfen Sie heraus SubSonic:

http://subsonicproject.com/

Answer 6

Ich denke, die Ziele der EDM unsere viel größer als die von LINQ to SQL. Wenn Sie einen einfachen ORM suchen, dann denke ich, LINQ to SQL ist der Weg zu gehen. Wenn Sie auf dem Aufbau in Klassen planen, die eine Vererbungsstruktur in Bezug auf Datenbanktabellen, die eine relationale Struktur und tun andere erweiterte Zuordnungen, dann EDM könnte eine gute Wahl sein.

Answer 7

Es ist erwähnenswert, dass diese Seite gebaut wird LINQ to SQL. Jeff sprach darüber auf dem Stackoverflow Podcast verwenden.

Answer 8

L2S ist eine wunderbare Technologie, und ich würde nie wieder in alter ADO gehen.

Aber wie Sie erwähnt, ist es in den Hintergrund rücken L2E nehmen. L2S ist mehr als fähig, und ich habe es zahlreiche Anwendungen mit ihm und war unglaublich zufrieden gemacht. Aber zu hören, dass es nicht mehr setzte in meiner Seite ein Messer vorgeschoben werden. Also ging ich L2E zu überprüfen, und es ist fast die gleiche Sache, wenn es darum geht, Interaktion SQL, und in vielerlei Hinsicht finde ich es einfacher, nicht effizienter mit seiner Beziehung Handhabung zu erwähnen. Mit einem solchen Ähnlichkeiten, scheint es logisch, L2E zu wählen.

Ich schrieb einen Beitrag über den Schalter zu machen und den Vergleich der beiden Frameworks: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

Ich kann fast garantieren, dass Sie mit einem dieser Frameworks glücklich sein, sie sind ein Geschenk des Himmels für die Entwicklung. Die Einfachheit und Fehlervermeidung ist unübertroffen. Ich persönlich würde zu L2E anlehnen, da es thatn L2S aggressiver entwickelt werden.

Answer 9

ich L2S verwenden stark auf meinem aktuellen Web-Projekt und ich glaube, die größte hangup finden Sie wird Dokumentation in Konflikt die beste Art und Weise in Bezug auf n-Tier-Datenbank-Entwicklung zu tun.

In erster Linie, was Sie brauchen im Voraus zu erkennen, heißt Datacontext Objekte sollen nur so lange, wie die Arbeitseinheit , Zeit dauern. Darüber hinaus sind die Datacontext staatenlos. Wenn Sie sich mit diesen beiden Prinzipien in den Griff bekommen, mit LINQ in einer n-Tier-Umgebung startet gut zu funktionieren.

Auf der anderen Seite finden Sie eine Reihe von Menschen zu sehen, einige sehr sehr sehr schlechte Wege empfehlen Linq zu verwenden. Nicht immer Ihre Datacontext statisch machen, das ist ein Fehler, den ich früh gemacht und es hat Wunder gewirkt, bis es nicht funktioniert hat, dann war es absolut schrecklich mit falschen Daten Kreuzung zwischen verschiedenen Sitzungen usw. Einfach gesagt, das ist vielleicht die größte gewaltigsten no-no Linq verwenden und soll in jedem Dokument in großen fetten Buchstaben geschrieben werden. Auch eine Datacontext in einem Session-Variablen persistierenden ist eine ebenso schlechte Idee.

Die einzige andere große böse Ich lief in mit LINQ wird, wenn ein getrenntes Update zu tun, müssen Sie die gleiche Datacontext über den gesamten Anruf nutzen. Zum Beispiel:

    public static void UpdateUser(UserLibrary.User user) {
        using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr))
        {
            UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault();
            newUser.Email = user.Email;
            newUser.FirstName = user.FirstName;
            newUser.LastName = user.LastName;
            dc.SubmitChanges();
        }        

Sie können nicht einfach in einem User-Pass in einem anderen Datacontext erstellt und erwarten aktualisieren, zu arbeiten, es sei denn Du DataContext.ObjectTrackingEnabled = false gesetzt, die ich nicht empfehlen würde. Stattdessen innerhalb der gleichen Datacontext sollten Sie das vorhandene Objekt abrufen, ihre Werte aktualisieren, gibt dann die Änderungen. Halten Sie alle wie Aufgaben innerhalb der gleichen Datacontext.

Ich würde empfehlen, L2S aber, wenn Sie ein paar nagenden Fragen erhalten über (wie oben), es ist eine großartige Technologie und definatly eine Zeitersparnis. Ich würde jedoch empfehlen eine dünne Hülle um Ihre DAL tun, so können Sie leicht ändern. Ich erwäge (aus wirtschaftlichen Gründen) zur Verwendung von Openaccess ORM einen Teil meiner Portieren von Code -> MySql für einen Teil meines Datenzugriff und mit einer richtig definierten Schicht, sollte diese Aufgabe übernimmt nur mir ein paar Stunden.

Answer 10

Ich bin mit Echostorm. L2S ist für Ihre Bedürfnisse gut. Und es ist ganz einfach, mit zu arbeiten ...

Answer 11

Wenn Sie Ihre Anwendung entwerfen richtig und isolieren Sie Ihren Datenzugriff und die Schicht, sollten Sie mit L2S gehen. Von dem, was ich aus Ihrem Post schließen, es ist kein großes Projekt, so L2S Ihre Anforderungen ganz gut erfüllen sollte, während das gute alte ADO.NET ist nur ein no-no, und Entity Framework, ist ... es einfach nicht verwenden , okay? Wie auch immer, wenn Sie Ihre DAL gut isolieren, können Sie L2S zu anderen in der Zukunft etwas tauschen, wenn das Projekt wächst. und selbst wenn L2S ist nicht überall, es ist nicht überall. MS blieb es investiert, aber es ist nicht veralteter oder etwas werden würde, so ist es immer noch eine sichere Investition. Alternativ sollten Sie NHibernate, bewerten, die einfach und ausgereift ist.