Linq to SQL für ein neues Projekt

Question

Ich bin im Begriff, ein neues Projekt zu starten und zu entscheiden, welche Datenzugriffstechnologie ich verwenden werde ... Ich mag LINQ to SQL aus einer Vielzahl von Gründen, aber sollte ich das neue Projekt starten Verwenden Sie stattdessen das Entity Framework?

Ich habe diese Wahrnehmung, dass das Entity Framework aufgeblähter und unnötigerweise komplizierter ist, was einen Teil des Grundes ausmacht, warum ich mit LINQ zu SQL überlegte ... aber wie ich sagte, kann dies nur Wahrnehmung auf meiner Seite sein weil ich das Entity Framework nicht so oft benutzt habe.

Also, was würden die Leute empfehlen, die ich benutze, um heute ein neues Projekt zu beginnen (beachten Sie, dass diese App für die nächsten Jahre noch da sein wird)?

Prost Anthony

EDIT: Wir SQL Server-Shop sind so unabhängig wir nicht brauchen, Datenbank-Anbieter.

Ist auch der allgemein beste Weg, um Datenzugriff atm zu abstrahieren, mit dem Repository-Muster, das mit meinen Domain-Objekten funktioniert?

Answer 1

Bei LINQ to SQL geht es um schnelle Entwicklung und Einfachheit. Wenn Ihr Datenmodell komplex ist oder werden könnte, sollten Sie ein robusteres Framework verwenden.

Das heißt, wichtiger als Ihr Datenzugriffstool ist, wie gut Sie es vom Rest Ihres Codes abstrahieren. Richtig gemacht, Sie sollten in der Lage sein, mit LINQ to SQL zu beginnen und zu wechseln, wenn Sie es verlassen (oder wenn EF 4 herauskommt).

Answer 2

Linq to SQL funktioniert am besten in einem aktiven Datensatz/einer Tabelle pro Klassenparadigma. Wenn Sie Ihre Klasse über mehrere Tabellen hinweg verteilen oder komplexe Vererbung unterstützen müssen, ist dies möglicherweise nicht die beste Wahl. Außerdem unterstützt Linq to SQL nativ keine Viele-zu-viele-Beziehungen (es gibt Problemumgehungen).

Wenn keiner von beiden klingt, als würden sie Sie betreffen, dann ist Linq 2 SQL eine gute Wahl. Es ist eine großartige, leichte Datenzugriffsstrategie.

Linq to SQL kann verwendet werden, um das Repository-Muster sehr gut zu implementieren, wenn die obigen Einschränkungen gelten. Google wird mehrere brauchbare Beispiele für Linq-Repositories aufzeigen.

Answer 3

Beachten Sie, dass EF 1 bei weitem nicht vollständig ist. Es fehlen alle Arten von Funktionen, die Sie in LINQ to SQL finden. Eine der wichtigeren Eigenschaften sind die Fremdschlüsseleigenschaften (können Sie sich vorstellen, dass diese in EF 1 nicht existieren?)

Auch EF 4 wird ziemlich viel über alle Funktionen von LINQ TO SQL verfügen, und beide werden relativ vergleichbare (Code-bezogene) externe API generieren. Wenn Sie also nicht zu sehr LINQ to SQL-spezifischen APIs codieren, sollte es relativ einfach sein, später zu EF4 zu migrieren. indem Sie LINQ to SQL .dbml durch das Äquivalent von EF4 ersetzen.

Answer 4

Haben Sie einen Blick auf Subsonic - jetzt in Version 3 ist es im Grunde eine LINQ zu SQL DAL, die es möglich macht, vollständige LINQ zu SQL Ihrer gesamten Datenbank in weniger als 5 Minuten. Und es läuft T4-Vorlagen aus, wenn Sie also zu den Vorlagen hinzufügen möchten, ist es einfach

http://www.subsonicproject.com/

Answer 5

Ich schrieb über die Wahl eines ziemlich langen Blog-Post auf.NET ORM:

.NET and ORM - Decisions, decisions

Grundsätzlich NHibernate ist die beste Wahl. Wenn Sie auf etwas Einfaches wie LinqToSql bestehen, sollten Sie SubSonic in Betracht ziehen. Ich würde keine der Microsoft-Optionen empfehlen: LinqToSql oder EntityFramework.

Die Entscheidung, ob das Repository-Muster verwendet werden soll oder nicht, hängt von Ihren Anforderungen ab.

Answer 6

Auschecken: http://www.icemanind.com/Layergen.aspx