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

Question

Ich habe untersucht, welche Datenschicht für ein neues webbasiertes Projekt verwendet werden soll, das ich entwerfe, und ich bin sehr daran interessiert, LINQ to SQL zu integrieren. Seine offensichtliche Einfachheit, Flexibilität und Designer-Unterstützung spricht wirklich an und die implizite Anbindung an SQL Server ist in Ordnung.

Kürzlich wurde jedoch bekannt gegeben, dass LINQ to SQL dem Entity Framework, das nun an das ADO.NET-Team übergeben wurde, einen Rückzieher macht (http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx). Sicher, es wird in Zukunft unterstützt werden, aber es ist unwahrscheinlich, dass es viel mehr Entwicklungsarbeit sehen wird.

Vor diesem Hintergrund würden Sie mir empfehlen, diese Technologie für mein Projekt zu verwenden, oder lohnt es sich, entweder ein alternatives ORM (nHibernate?) Auszuwählen oder ein generisches DAL manuell zu codieren?

Das Projekt selbst basiert auf ASP.NET und SQL Server 2005/2008 und wird möglicherweise MVC verwenden, obwohl es noch in der Betaversion ist. Es ist ein persönliches Projekt, die Datenbank wird nicht übermäßig komplex sein und wird hauptsächlich als Prototyp für .NET Future Tech verwendet werden. Ich würde zukünftige Projekte auf das aufbauen, was ich daraus lerne, also werden die Entscheidungen, die ich treffe, größere zukünftige Lösungen beeinflussen.

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

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 aus meiner Sicht etwas zu einfach an. In den meisten Fällen macht es gute Arbeit, einfache Dinge zu tun, aber sobald Sie ein wenig mehr davon verlangen, wird es teuer. Das ist überhaupt keine schlechte Sache. Ich glaube tatsächlich, dass LINQ to SQL das Entity Framework sehr gut ergänzt.

Nehmen Sie Auto-Paging mit LinqDataSource zum Beispiel. Wenn Sie Order By/Group By nicht angeben, ist das sehr ökonomisch. Wirf Ordnung oder Gruppierung in die Mischung und du bekommst eine Leistungssteigerung (wird sehr geschwätzig). Sie müssen dann ziemlich genau Ihre eigene Paging-Implementierung schreiben (was nicht besonders schwer ist, gebe ich zu).

Ich bin der erste, zuzugeben, dass L2S hat den Vorteil gegenüber dem Entity Framework in Bezug auf die Qualität der generierten T-SQL (ich sollte, da L2S ist speziell für die Abfrage von SQL Server erstellt) und konzeptionell und symbolisch Ein großer Teil von LINQ to SQL ist EF ähnlich, aber wo Sie an die Wand gehen, geht es darum, die Anforderungen und die Berücksichtigung komplizierterer Implementierungsanforderungen zu erweitern.

Wenn ich von vorne anfange und mich entscheide, persönliche Entwicklungszeit zu widmen, würde ich das Entity Framework wählen. Interessanterweise arbeite ich gerade an einem Projekt, das L2S verwendet, und es wurde entwickelt, um große Lasten zu bewältigen, aber wenn wir einige der "kreativen" Anforderungen erfüllen, sind wir oft gezwungen, SQL Metal zu erweitern (zB Viele-zu-Viele-Beziehungen)

Also .. kurz gesagt .. Ich würde es so nähern:

a) lernen LINQ als Intro to SQL (Microsofts ORM Muster und Technologie) ..Es macht Sie vertraut mit den meisten Grundlagen, die mit dem Entity Framework geteilt werden, und einem Vorgeschmack auf LINQ Style Querying (ein erworbener Vorgeschmack, wenn Sie einen Hintergrund in T-SQL haben) b) sobald Sie eine haben LINQ to SQL, würde ich empfehlen, zum Entity Framework zu springen, um die zusätzlichen Vorteile (eSQL usw.) zu lernen.

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

Answer 2

Wählen Sie NHibernate. Es wird für einige Zeit als ein Konzept oder das eigentliche ORM bleiben. So wird es nützlich sein, beides zu lernen.

Answer 3

L2S ist, IMHO, völlig in Ordnung, wie es ist und wie Sie gesagt haben, geht nirgendwo hin. Das Unternehmen, für das ich arbeite, hat es zu unserem Standard für den Datenzugriff gemacht und wir verwenden es für alles, von kleinen 5 Nischen-Apps bis hin zu über 1000 Benutzer-Enterprise-Apps mit großartigen Ergebnissen.

Answer 4

Check out SubSonic:

http://subsonicproject.com/

Answer 5

denke ich, dass die Ziele der EDM unsere viel größer als die von LINQ to SQL. Wenn Sie nach einem einfachen ORM suchen, dann ist LINQ to SQL der richtige Weg. Wenn Sie planen, Klassen zu erstellen, die eine Vererbungsstruktur in Bezug auf Datenbanktabellen mit einer relationalen Struktur aufweisen, und andere erweiterte Zuordnungen vornehmen, ist EDM möglicherweise eine gute Wahl.

Answer 6

IMO, dieses ganze Ding wurde wirklich überproportional ausgeblasen.

Microsoft hat nicht gesagt, dass LINQ zu SQL tot wäre. Sie deuteten mehr an, dass es in Entity Framework zusammengeführt würde.

Ich würde mich darauf konzentrieren, Entity Framework als Lösung zu verwenden, da ich weiß, dass ein Großteil von LINQ to SQL hineingerollt wird.

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

Answer 7

Ich stimme Echostorm. L2S ist gut für Ihre Bedürfnisse. Und es ist ziemlich einfach mit ...

Answer 8

zu arbeiten Es ist erwähnenswert, dass diese Seite mit LINQ to SQL erstellt wird. Jeff sprach davon, ihn im StackOverflow-Podcast zu verwenden.

Answer 9

L2S ist eine tolle Technologie, und ich würde nie wieder zu alten ADO gehen.

Aber wie Sie erwähnt haben, nimmt es auf dem Rücksitz zu L2E. L2S ist mehr als fähig und ich habe zahlreiche Anwendungen damit gemacht und bin unglaublich zufrieden gewesen. Aber wenn ich höre, dass es nicht mehr weitergeht, steck mir ein Messer in die Seite. Also ging ich L2E zu überprüfen und es ist fast die gleiche Sache, wenn es um SQL-Interaktion geht, und in vielerlei Hinsicht finde ich es einfacher, nicht zu erwähnen effizienter mit seiner Beziehung Handhabung. Bei solchen Ähnlichkeiten erscheint es logisch, L2E zu wählen.

schrieb ich 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 fast garantieren, dass Sie mit einem dieser Frameworks glücklich sein, sie ein Geschenk des Himmels für die Entwicklung sind. Die Einfachheit und Fehlervermeidung ist unübertroffen. Ich würde mich persönlich an L2E lehnen, da dieser L2S aggressiver entwickelt wird.

Answer 10

Wenn Sie Ihre App richtig entwerfen und Ihre Datenzugriffsebene gut isolieren, sollten Sie L2S verwenden. Aus dem, was ich aus Ihrem Post folge, ist es kein großes Projekt, also sollte L2S Ihre Anforderungen gut erfüllen, während schlichtweg altes ADO.NET nur ein No-No ist, und Entity Framework, ist ... einfach nicht verwenden , OK? Wie auch immer, wenn Sie Ihre DAL gut isolieren, können Sie L2S zu etwas anderem in der Zukunft tauschen, wenn das Projekt wächst. und selbst wenn L2S nirgendwohin geht, wird es nirgendwohin gehen. MS hat damit aufgehört zu investieren, aber es wird nicht veraltet sein oder so, also ist es immer noch eine sichere Investition. Alternativ sollten Sie NHibernate evaluieren, das einfach und ausgereift ist.

Answer 11

Ich benutze L2S stark auf meinem aktuellen Web-Projekt und ich glaube, dass der größte Hangup, den Sie finden werden, widersprüchliche Dokumentation in Bezug auf die beste Möglichkeit ist, n-Tier-Datenbank-Entwicklung zu tun.

In erster Linie, was Sie im Voraus zu realisieren müssen, sind DataContext-Objekte sind nur so lange dauern als Arbeitseinheit, Punkt. Darüber hinaus sind DataContext staatenlos. Sobald Sie sich mit diesen beiden Prinzipien vertraut gemacht haben, beginnt die Verwendung von LINQ in einer n-Tier-Umgebung gut zu funktionieren.

Auf der anderen Seite werden Sie eine Reihe von Leuten sehen, die sehr, sehr, sehr schlechte Wege empfehlen, Linq zu benutzen. Machen Sie Ihren DataContext nicht immer statisch, das ist ein Fehler, den ich früh gemacht habe und er hat Wunder gewirkt, bis er nicht funktionierte, dann war es absolut schrecklich, wenn falsche Daten über verschiedene Sessions hinweg laufen, etc. Einfach gesagt, das ist vielleicht das Größte gigantisches no-no von Linq und sollte in jedem Dokument in großen fetten Buchstaben geschrieben werden. Auch das Fortbestehen eines DataContext in einer Session-Variablen ist eine ebenso schlechte Idee.

Das einzige andere größere Problem, das ich mit LINQ hatte, ist, wenn Sie ein getrenntes Update durchführen, müssen Sie den gleichen DataContext für den gesamten Anruf verwenden. 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 sollten Sie innerhalb des gleichen DataContext das vorhandene Objekt abrufen, seine Werte aktualisieren und dann diese Änderungen übermitteln. Behalte alle ähnlichen Aufgaben im selben DataContext.

Ich würde L2S aber empfehlen, sobald Sie über ein paar Niggling Probleme (wie oben), es ist eine großartige Technologie und auf jeden Fall eine Zeitersparnis. Ich würde jedoch empfehlen, einen dünnen Wrapper rund um Ihren DAL zu verwenden, damit Sie ihn leicht wechseln können. Ich überlege (aus wirtschaftlichen Gründen), einen Teil meines Codes für einen Teil meines Datenzugriffs auf OpenAccess ORM -> MySql zu portieren, und mit einer richtig definierten Schicht sollte diese Aufgabe nur ein paar Stunden dauern.