Wenn Sie ein neues Projekt beginnen, sollten Sie sich zunächst für Entity Framework ("EF") entscheiden - es generiert jetzt viel besseres SQL (ähnlich wie Linq to SQL) und ist einfacher zu warten und leistungsfähiger als Linq to SQL ("L2S"). Seit der Veröffentlichung von .NET 4.0 betrachte ich Linq to SQL als eine veraltete Technologie. MS hat sich sehr offen dazu geäußert, die Entwicklung von L2S nicht weiter voranzutreiben.
1) Leistung
Diese Frage ist schwierig zu beantworten. Bei den meisten Vorgängen, die nur eine Einheit betreffen ( CRUD ) werden Sie mit allen drei Technologien eine nahezu gleichwertige Leistung erzielen. Sie müssen allerdings wissen, wie EF und Linq to SQL funktionieren, um sie optimal nutzen zu können. Für hochvolumige Operationen wie Abfragen sollten Sie EF/L2S Ihre Entitätsabfrage "kompilieren" lassen, damit das Framework die SQL nicht ständig neu generieren muss, da es sonst zu Skalierungsproblemen kommen kann. (siehe Bearbeitungen)
Für Massenaktualisierungen, bei denen Sie große Datenmengen aktualisieren, ist Roh-SQL oder eine gespeicherte Prozedur immer leistungsfähiger als eine ORM-Lösung, da Sie die Daten nicht über die Leitung zum ORM transportieren müssen, um Aktualisierungen durchzuführen.
2) Geschwindigkeit der Entwicklung
In den meisten Szenarien wird EF naked SQL/stored procs in puncto Entwicklungsgeschwindigkeit in den Schatten stellen. Der EF-Designer kann Ihr Modell von Ihrer Datenbank aus aktualisieren, wenn es sich ändert (auf Anfrage), so dass Sie keine Probleme mit der Synchronisierung zwischen Ihrem Objektcode und Ihrem Datenbankcode haben. Die einzige Zeit, in der ich die Verwendung eines ORM nicht in Betracht ziehen würde, ist, wenn Sie eine Anwendung vom Typ Bericht/Dashboard erstellen, in der Sie keine Aktualisierungen vornehmen, oder wenn Sie eine Anwendung erstellen, die nur zur Pflege von Rohdaten in einer Datenbank dient.
3) Ordentlicher/wartbarer Code
EF ist zweifellos besser als SQL/sprocs. Da Ihre Beziehungen modelliert sind, kommen Joins in Ihrem Code relativ selten vor. Die Beziehungen zwischen den Entitäten sind für den Leser bei den meisten Abfragen fast selbstverständlich. Nichts ist schlimmer, als von einer Ebene zur anderen gehen zu müssen, um zu debuggen oder mehrere SQL/Middle-Tiers zu durchlaufen, um zu verstehen, was eigentlich mit Ihren Daten geschieht. EF bringt Ihr Datenmodell auf eine sehr leistungsfähige Weise in Ihren Code ein.
4) Flexibilität
Stored Procs und Raw SQL sind "flexibler". Sie können Sprocs und SQL nutzen, um schnellere Abfragen für den einen oder anderen Sonderfall zu generieren, und Sie können die native DB-Funktionalität leichter nutzen als mit einem ORM.
5) Insgesamt
Lassen Sie sich nicht von der falschen Dichotomie zwischen ORM und gespeicherten Prozeduren einwickeln. Sie können beide in derselben Anwendung verwenden, und das sollten Sie auch tun. Große Massenoperationen sollten in gespeicherten Prozeduren oder SQL (die tatsächlich von EF aufgerufen werden können) durchgeführt werden, und EF sollte für Ihre CRUD-Operationen und die meisten Bedürfnisse Ihrer mittleren Schicht verwendet werden. Vielleicht möchten Sie SQL für die Erstellung Ihrer Berichte verwenden. Ich denke, die Moral der Geschichte ist die gleiche wie immer. Verwenden Sie das richtige Werkzeug für die jeweilige Aufgabe. Aber das Entscheidende ist, dass EF heutzutage sehr gut ist (seit .NET 4.0). Verbringen Sie etwas Zeit damit, es gründlich zu lesen und zu verstehen, und Sie können mit Leichtigkeit einige erstaunliche, leistungsstarke Anwendungen erstellen.
EDIT : EF 5 vereinfacht diesen Teil ein wenig mit automatisch kompilierte LINQ-Abfragen Aber wenn es um wirklich große Mengen geht, müssen Sie auf jeden Fall testen und analysieren, was für Sie in der realen Welt am besten geeignet ist.
