Verpasst Linq to SQL nicht den Punkt? Sind ORM-Mapper (SubSonic usw.) nicht suboptimale Lösungen?

Ich möchte, dass die Community einige Gedanken zu Linq to Sql und anderen ORM-Mappern aufgreift.

Ich mag Linq to Sql und die Idee, Datenzugriffslogik (oder CRUD-Operationen im Allgemeinen) in Ihrer Muttersprache auszudrücken, anstatt sich mit der "Impedanzfehlanpassung" zwischen C # und SQL befassen zu müssen. Um beispielsweise eine ObjectDataSource-kompatible Liste von Ereignisinstanzen für eine Geschäftsschicht zurückzugeben, verwenden wir:

return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })

Wenn ich dies mit alten SQL-to-C # -Konstrukten implementieren würde, müsste ich eine Command-Klasse erstellen, den EventID-Parameter hinzufügen (mit einer Zeichenfolge das Argument "@EventID" beschreiben) und die SQL-Abfragezeichenfolge hinzufügen Befehlsklasse, führen Sie den Befehl aus und verwenden Sie dann (vom Typ cast) nwReader ["FieldName"], um jeden zurückgegebenen Feldwert abzurufen und einem Mitglied einer neu erstellten Instanz meiner EventData-Klasse zuzuweisen (yuck).

Also, dass ist , warum Leute wie Linq / SubSonic / etc. und ich stimme zu.

Im Großen und Ganzen sehe ich jedoch eine Reihe von Dingen, die falsch sind. Meiner Meinung nach sieht Microsoft auch etwas falsch und deshalb töten sie Linq zu SQL und versuchen, Leute zu Linq zu Entitäten zu bewegen. Nur denke ich, dass Microsoft eine schlechte Wette verdoppelt.

Also, was ist los?

Das Problem ist, dass es Architekturastronauten gibt , insbesondere bei Microsoft, die Linq to Sql betrachten und erkennen, dass es sich nicht um ein echtes Datenverwaltungstool handelt: Es gibt immer noch viele Dinge, die Sie in C # nicht einfach und bequem erledigen können, und die darauf abzielen, sie zu beheben . Sie sehen dies in den Ambitionen hinter Linq to Entities, Blog-Posts über die revolutionäre Natur von Linq und sogar in der LinqPad-Herausforderung .

Und das Problem mit , dass ist , dass es davon ausgeht , dass SQL das Problem ist. Das heißt, um ein leichtes Unbehagen (Impedanzfehlanpassung zwischen SQL und C #) zu verringern, hat Microsoft das Äquivalent eines Raumanzugs (vollständige Isolierung) vorgeschlagen, wenn ein Pflaster (Linq to SQL oder ähnliches) in Ordnung wäre.

Soweit ich sehen kann, sind Entwickler ziemlich klug genug, um das relationale Modell zu beherrschen und es dann intelligent in ihren Entwicklungsbemühungen anzuwenden. In der Tat würde ich noch einen Schritt weiter gehen und sagen, dass Linq to SQL, SubSonic usw. bereits zu komplex sind: Die Lernkurve unterscheidet sich nicht wesentlich von der Beherrschung von SQL selbst. Da Entwickler auf absehbare Zeit SQL und das relationale Modell beherrschen müssen , müssen wir jetzt zwei Abfrage- / CRUD-Sprachen lernen. Schlimmer noch, Linq ist oft schwer zu testen (Sie haben kein Abfragefenster), entfernt uns eine Ebene von unserer eigentlichen Arbeit (es generiert SQL) und bietet (bestenfalls) sehr ungeschickte Unterstützung für SQL-Konstrukte wie Datumsbehandlung (zB DateDiff), "Haben" und sogar "Gruppieren nach".

Was ist die Alternative? Persönlich benötige ich kein anderes Modell für den Datenzugriff wie Linq to Entities. Ich würde es vorziehen, einfach ein Fenster in Visual Studio zu öffnen, mein SQL einzugeben und zu validieren und dann eine Taste zu drücken, um eine C # -Klasse zu generieren oder zu ergänzen, um den Aufruf zu kapseln. Da Sie SQL bereits kennen, möchten Sie nicht einfach Folgendes eingeben:

Select EventID, Title From Events Where Location=@Location

und am Ende eine EventData-Klasse haben, die A) die Felder EventID und Title als Eigenschaften enthält und B) eine Factory-Methode hat, die eine 'Location'-Zeichenfolge als Argument verwendet und eine Liste <EventData> generiert? Sie müssten sorgfältig über das Objektmodell nachdenken (das obige Beispiel behandelt das offensichtlich nicht), aber der grundlegende Ansatz, SQL weiterhin zu verwenden und gleichzeitig die Impedanzfehlanpassung zu beseitigen, gefällt mir sehr gut.

Die Frage ist: irre ich mich? Sollte Microsoft die SQL-Infrastruktur neu schreiben, damit Sie SQL / relationale Datenverwaltung nicht mehr lernen müssen? Können sie die SQL-Infrastruktur auf diese Weise neu schreiben? Oder denken Sie, dass eine sehr dünne Schicht über SQL, um das Einrichten von Parametern und den Zugriff auf Datenfelder zu vermeiden, völlig ausreicht?

Update Ich wollte zwei Links nach oben bewerben, weil ich denke, dass sie wichtige Aspekte von dem erfassen, wonach ich suche. Zunächst weist CodeMonkey auf einen Artikel mit dem Titel "Das Vietnam der Informatik" hin. Der Einstieg dauert eine Weile, ist aber eine sehr interessante Lektüre. Zweitens verweist AnSGri auf eines der bekanntesten Stücke von Joel Spolsky: Das Gesetz der undichten Abstraktionen . Es ist nicht genau zum Thema, aber es ist nah und eine gute Lektüre.

Update 2: Ich habe ocdecio die "Antwort" gegeben, obwohl es hier viele gute Antworten gibt und die Wahl der "richtigen" Antwort rein subjektiv ist. In diesem Fall stimmte seine Antwort mit dem überein, was ich angesichts des aktuellen Standes der Technik für die beste Vorgehensweise halte. Dies ist ein Bereich, von dem ich jedoch voll und ganz erwarte, dass er sich weiterentwickelt, sodass sich die Dinge möglicherweise ändern. Ich möchte mich bei allen bedanken, die dazu beigetragen haben. Ich habe alle positiv bewertet, von denen ich denke, dass sie eine nachdenkliche Antwort gegeben haben.

Seit mindestens 6 Jahren verwende ich mein eigenes ORM, das auf einem sehr einfachen Konzept basiert: Projektion. Jede Tabelle wird in eine Klasse projiziert, und SQL wird basierend auf der Klassendefinition im laufenden Betrieb generiert. Ich muss immer noch SQL kennen, aber es kümmert sich um die 90% einfache CRUD, und ich musste nie Verbindungen usw. verwalten - und es funktioniert für die großen DB-Anbieter.

Ich bin zufrieden mit dem, was ich habe und habe nichts gefunden, wofür es sich lohnt, es fallen zu lassen.

Lassen Sie mich dies vorwegnehmen, indem Sie sagen, dass ich ein eingefleischter Datenbank-Typ bin.

Als grobe Überverallgemeinerung : Entwickler kennen SQL nicht. Entwickler wollen SQLnicht wirklichkennen. Sie können es schreiben, sie können Tabellen entwerfen, aber es macht sie eklig. Sie neigen dazu, dumme Dinge zu tun, wenn die notwendige Abfrage mehr als eine einfache Verknüpfung ist. Nicht weil die Entwickler dumm sind - weil sie nicht gestört werden können. Sie leben gerne in einer Welt, in der sie sich nur mit einem Konzeptraum auseinandersetzen müssen. Das Verschieben von Objekten zu Tabellen und zurück ist ein Kontextwechsel des Preises, für den sie nicht gerne zahlen.

Dies bedeutet nicht, dass sie schlecht oder falsch sind. es bedeutet, dass es Verbesserungsmöglichkeiten gibt. Wenn Ihre Kunden (in diesem Fall Entwickler, die Ihr Framework verwenden) SQL und Tabellen nicht mögen, geben Sie ihnen eine Abstraktionsebene, mit der sie davonkommen können, ohne sich mit dem zugrunde liegenden Durcheinander zu befassen.

Es ist dieselbe Logik, die die Speicherbereinigung / automatisierte Speicherverwaltung zu einem großen Erfolg macht. Ja, Entwickler können damit umgehen. Ja, sie können Code schreiben, der ohne ihn besser optimiert ist. Aber wenn sie sich nicht damit auseinandersetzen müssen, sind sie glücklicher und produktiver.

Ich denke, die Popularität von ORMs wurde von Entwicklern hervorgerufen, die Datenschichten entwickelten und immer wieder denselben CRUD-Code Anwendung für Anwendung schrieben. ORMs sind nur ein weiteres Tool / eine andere Technologie, mit der Entwickler weniger Zeit damit verbringen, dieselben SQL-Anweisungen immer wieder zu schreiben und sich stattdessen (hoffentlich) auf die Logik der Anwendung zu konzentrieren.

IMHO, OR / M geht es nicht nur darum, das SQL zu abstrahieren, das SQL zu verbergen oder die Unterstützung für mehrere DBMS zu aktivieren.

Sie können sich mehr auf Ihre Problemdomäne konzentrieren, da Sie weniger Zeit für das Schreiben der langweiligen CRUD SQL-Abfragen aufwenden müssen. Wenn Sie dagegen ein gutes OR / M verwenden, sollte dieses OR / M es Ihnen ermöglichen, SQL-Abfragen zu schreiben, wenn dies notwendig erscheint.

Ein OR / M kann ein leistungsfähiges Werkzeug sein, wenn Sie es richtig verwenden. es kann sich um faules Laden, polymorphe Abfragen / Assoziationen kümmern ...
Versteh mich nicht falsch; An einfachem SQL ist nichts auszusetzen, aber wenn Sie sich darum kümmern müssen, Ihr (gut durchdachtes und normalisiertes) relationales Modell in ein ausdrucksstarkes OO / Domain-Modell zu übersetzen, dann verbringen Sie wahrscheinlich viel zu viel Zeit mit der Installation.

Die Verwendung eines OR / M bedeutet auch nicht, dass Sie als Entwickler keine SQL-Kenntnisse haben sollten. Das Gegenteil ist imho wahr.
Wenn Sie SQL kennen und wissen, wie man eine effiziente SQL-Abfrage schreibt, können Sie -imho- ein OR / M richtig verwenden.

Ich muss auch zugeben, dass ich dies mit Blick auf NHibernate schreibe. Dies ist der OR / M, den ich atm verwende, und ich habe Linq to SQL oder Linq to entity (noch) nicht verwendet.

Das Design von Linq und das Linq to Entities-Framework werden sicherlich als Orm-Tool verwendet, aber die große Idee ist, dass es als allgemeine API zum Abfragen JEDER Datenquelle verwendet wird, nicht nur von RDBMS.

Ich erinnere mich, dass ich gelesen habe, dass linq, obwohl es offensichtlich für SQL entwickelt wurde, eine Abfragesprache für jeden Datenspeicher sein soll. Sie können Linq-Abfragen für SQL schreiben, aber Sie können theoretisch auch Linq-Abfragen schreiben, die auf LDAP, Dateisysteme, Austausch, Webdienste und ad infinitum abzielen. Sie können SQL für diese Programme nicht verwenden.

Sie müssen auch für fast jeden Datenspeicher eine andere API lernen. Linq gibt jedem ein gemeinsames Ziel zum Erstellen einer Datenzugriffs-API.

Ob diese Vision funktioniert oder nicht, bleibt abzuwarten, aber das ist die Idee. Ich denke, da wir wollen, dass Systeme immer mehr zusammenarbeiten, finden wir möglicherweise einige sehr gute Verwendungsmöglichkeiten für l2e.

Ich werde einige Referenzen hinzufügen, wenn ich sie wieder finde.

http://laribee.com/blog/2007/03/17/linq-to-entities-vs-nhibernate/

Sie sollten aufhören, sich Sorgen zu machen und lernen, das ORM zu lieben. Abstraktionen wie diese helfen uns, unsere Fähigkeiten zu fokussieren und Fortschritte auf diesem Gebiet zu erzielen.

Es gibt noch viel Raum, um die erworbenen funktionalen Fähigkeiten zu nutzen und sie in der Anwendungsebene anzuwenden. Dies ist in der Tat eine der Stärken von LINQ to SQL gegenüber anderen ORMs.

Ich kann nur vielen anderen Kommentaren zustimmen. Wenn Sie Zeit sparen, können Sie sich darauf konzentrieren, Ihr Domain-Modell zu verfeinern und eine bessere Anwendung zu erstellen. Wenn Sie den Engpass erkannt haben, können Sie damit optimiertes SQL erstellen.

Was möglicherweise nicht sofort offensichtlich ist, ist, dass das ORM eine Reihe von Funktionen bietet, die wirklich nett sind. Die Identitätszuordnung, die das wiederholte Laden von Elementen verhindert, das verzögerte Laden hilft Ihnen, die Domäne mit weniger Aufwand auszudrücken, und die Arbeitseinheit hilft Ihnen, Änderungen zu verfolgen und Datenbankschreibvorgänge zu optimieren.

Ich stimme zu 100% zu%. Ein Großteil davon ist auf die Tatsache zurückzuführen, dass die Fähigkeiten zur prozeduralen Codierung und zur SQL-Codierung sehr unterschiedlich sind. und diese Tatsache ist nicht allgemein anerkannt. Bis diese Erkenntnis eintrifft, suchen Programmierer nach Möglichkeiten, ihre Fähigkeiten von einer Domäne auf die andere übertragbar zu machen.

Es funktioniert nicht.

Sie müssen einfach lernen, wie man eine Phasenverschiebung durchführt: Lernen Sie, wie Sie Ihren Code je nach der von Ihnen angesprochenen Domäne unterschiedlich betrachten.

Hat jemand anderes bemerkt, wie viel komplexer und ausführlicher eine Abfrage wird, wenn sie von SQL auf LINQ abgebildet wird? Wie in allen Online-Beispielen?

Wie Dmitriy betonte , kennen Entwickler SQL nicht. Genauer gesagt, die Mehrheit kennt SQL, versteht es aber nicht und mag es definitiv nicht. Daher neigen sie dazu, nach dem Wundermittel zu suchen, was die Nachfrage nach Dingen wie Linq erzeugt, um die Illusion (hm, Abstraktion) zu erzeugen, die sie anziehen Verwenden Sie nichts anderes als ihre geliebten Klassen.

Das ist sehr schlecht, da das Gesetz der undichten Abstraktionen immer gilt.

Einige ORM-Lösungen sind definitiv gut (z. B. JPA / Hibernate), nicht weil Sie sich bei ihrer Verwendung keine Gedanken über SQL machen müssen. Um JPA effektiv nutzen zu können, benötigen Sie ein sehr tiefes Verständnis der Datenbank im Allgemeinen und der Abfrage von Fähigkeiten im Besonderen. Der gute Punkt ist, dass sie die Maschine dazu bringen, die langweilige Arbeit zu erledigen , bis zu dem Punkt, an dem die gesamte Datenbank automatisch von Grund auf neu generiert wird.

Linq to SQL löst, wie ich denke, kein wirkliches Problem. Es ist eine Art andere Präsentation, nichts weiter. Es könnte gut sein, obwohl es die bereits komplexe Sprache überkompliziert. Auf der anderen Seite ist Linq to Objects ein sehr interessantes Konzept, da es eine Art SQL-Abfrage der Sammlungen ist.

Historische Perspektive.

Als Codd et. al. Ursprünglich wurde die Theorie und Implementierung relationaler Datenbanken ausgearbeitet. Ein völlig anderes Thema war "Wie fragen wir diese Dinge ab?". Es wurde eine Reihe von Strategien und Syntaxen mit verschiedenen Stärken und Schwächen vorgeschlagen. Einer dieser Kandidaten war SQL (offensichtlich in seiner frühesten Form). Ein anderer war QBE (Query By Example). Ein anderer hieß "quel", glaube ich; und es gab mehrere andere. SQL wurde sicherlich nicht dominant, da es allen anderen als überlegen anerkannt wurde. Leider sind die anderen in der Armut von uns allen so gut wie verschwunden (weil sie gleichzeitig für dieselben Daten verwendet werden könnten).

Wenn Microsoft eine gute Geschichte hat, dass sie eine dieser anderen Sprachen wiederbeleben oder eine würdige Ergänzung erfunden haben, dann sind wir meiner Meinung nach gut beraten, zuzuhören. Aber bis jetzt habe ich nur noch einen "Ein Ring, der sie alle regiert" gesehen.

Hinter SQL steckt eine Menge Nachdenken und Genauigkeit sowie eine Menge bewährter Haltbarkeit. Microsoft glaubt seit jeher, dass seine zugegebenermaßen erstklassige Entwicklungsorganisation den Rest von uns, einschließlich unserer kollektiven institutionellen Erinnerungen, überdenken kann. Es scheint nicht oft so zu funktionieren. Solange wir an relationale Datenspeicher gebunden sind, sollten wir uns zweimal überlegen, ob Superset-Abstraktionsparadigmen uns mit dem Versprechen gleicher oder besserer Leistung vom Bare Metal abbringen.

Da ich selbst Autor eines ORM-Projekts bin, muss ich zugeben, dass meine Antwort auf eine solche Frage etwas voreingenommen ist. Ich habe bereits einige meiner eigenen Gedanken über die Antwort entwickelt, bevor ich die Frage gelesen habe, daher bin ich bereits etwas verankert.

Ich werde sagen, dass mein Grund für die Entwicklung eines ORM nicht in der "Impedanzfehlanpassung" zwischen SQL und zwingender Programmierung lag, sondern ausschließlich darin, datenbankplattformunabhängig zu werden. Das frühere Problem, mehr Code schreiben zu müssen, um die Persistenz zu verwalten, ist eine kleine Hürde, die leicht gelöst werden kann, wenn Sie nur mit einem Datenbankanbieter zusammenarbeiten. Agnostiker der Datenbankplattform zu werden, ist ein viel schwierigeres Problem, und imo hat einen viel größeren Einfluss auf die Rentabilität Ihres Unternehmens, vorausgesetzt, Sie planen wie ich, Software an andere Personen zu verkaufen (und verwenden sie nicht nur intern).

Als ich vor einigen Jahren anfing, an meinen ORM-Tools zu arbeiten, war das Konzept in meiner bevorzugten Sprache unpraktisch. Die meisten Leute, mit denen ich sprach, verstanden nicht, warum ich daran arbeitete, und einige angesehene Stimmen in der Community hatten so viel wie geschriebene Artikel in Fachzeitschriften heißt es, dass das, was ich bereits getan habe, nicht nur unmöglich, sondern auch unerwünscht sei. Einige der gleichen Gründe wurden angegeben - es ist zu komplex, es ist einschränkend und es erhöht den Overhead. Heutzutage verfügt dieselbe Community über mindestens drei beliebte Tools zur Datenbankabstraktion (obwohl über die Definition des Begriffs ORM diskutiert wird). Der Grund, warum ich dies erwähne, ist, dass die ursprünglichen Einwände, als ich anfing, an diesen Werkzeugen zu arbeiten, viel mehr Gewicht hatten als jetzt. Die zugrunde liegende Technologie, sowohl Hardware als auch Software, hat sich in den vergangenen Jahren geändert, um diese Tools auf lange Sicht viel praktischer zu machen. Meine Tendenz ist es, eine lange Sicht auf Software zu haben und an Lösungen zu arbeiten, die vielleicht noch nicht ganz praktisch sind, aber bald praktisch werden. Angesichts der Tatsache, dass ich LINQ to Entities nicht als gute Lösung für bestimmte Probleme betrachten würde.

Ich bevorzuge auch eher mehr Optionen als weniger. Obwohl ich die Idee hinter der Entwicklung von LINQ to Entities unterstützen kann, bin ich weniger geneigt, das Beenden von LINQ to SQL zu unterstützen, nur weil LINQ to Entities verfügbar geworden ist. Objekte sind großartig, um das zu tun, was Objekte tun, das steht außer Frage ... Meiner (wieder voreingenommenen) Meinung nach tritt ein Problem darin auf, dass Menschen ein bestimmtes Tool- oder Software-Paradigma als "Wundermittel" betrachten und darauf bestehen wollen, dass alles muss so sein. Es ist bekannt, dass eine relationale Datenbank bestimmte andere Aufgaben sehr gut erledigen kann, wobei die Berichterstellung ein gutes Beispiel ist. Meiner Meinung nach ist es eine Art, sich in den Fuß zu schießen, um darauf zu bestehen, dass alles Entitäten sein müssen, denn dann zwingen Sie sich, ein ineffizientes Werkzeug für den Job zu verwenden. So insbesondere im Hinblick auf die Berichterstattung,Abstraktionsinversion Anti-Muster.

Die Zusammenfassung für meine Antwort lautet also: Verwenden Sie einen Hammer, wenn Ihr Problem ein Nagel ist - verwenden Sie einen Schraubenzieher, wenn Ihr Problem eine Schraube ist.

Dmitrys Aussage, dass Entwickler SQL nicht mögen, mag viel Wahres enthalten, aber die Lösung ist nicht nur ORM. Die Lösung besteht darin, als Teil des Entwicklungsteams einen Entwicklungs-DBA einzustellen. In meiner Firma hat mein .net-Entwicklungsteam einen exzellenten Oracle-DBA, der absolut keine Produktions-DBA-Arbeit leistet. Seine Rolle in unserem Team ist Datenmodellierung, physisches Datenbankdesign, Erstellen gespeicherter Prozesse, Datenanalyse usw. Er ist der Grund, warum unsere Datenbankseite so sauber und leistungsfähig ist. Der gesamte DB-Zugriff erfolgt über gespeicherte Prozesse.

Was ist ein Entwicklungs-DBA? http://www.simple-talk.com/sql/database-administration/what-use-is-a-development-dba/

Ich programmiere sowohl Datenbanken als auch verteilte Anwendungen (Web und kompiliert) und habe das Gefühl, dass die Zeit für die Entwicklung von Datenzugriffsschichten auf Basis gespeicherter Prozeduren gut angelegt ist. Persönlich bevorzuge ich die Datenmodellierung und identifiziere die benötigten Prozesse früh im Entwicklungsprozess ... scheint dabei zu helfen, Design- / Schnittstellenlogik- / Strukturprobleme aufzudecken.

Ich bin kein großer Fan von Inline-Datenbankprogrammierung (egal ob der SQL-Code von Hand oder maschinengeneriert ist). Ich glaube, dass die Datenbank die Grundlage für die eigene Anwendung ist und dass es sich lohnt, sich die Zeit zu nehmen, um gespeicherte Prozesse von Hand zu codieren.

Trotzdem bin ich vom OODBMS-Konzept fasziniert und hoffe, dass ich eines Tages in einer Produktionsumgebung an einigen arbeiten kann.

Wenn Sie möchten, dass eine Datenbank skalierbar ist, muss sie gemäß den Best Practices für relationale Datenbankmodelle entworfen und normalisiert werden.

Wenn Sie das Objektmodell und das ORM Ihr Datenmodell bestimmen lassen, erhalten Sie nur ein schlechtes Datenmodell, das nicht normalisiert ist und / oder Artefakte aus dem Objektmodell enthält.

1 Tabelle = 1 Klasse ist eine schlechte Idee.

Zunächst einmal haben Sie niemals Klassen, die viele-zu-viele oder viele-zu-eins-Verknüpfungstabellen darstellen. Diese entsprechen untergeordneten Sammlungen im Objektmodell - die Links selbst sind keine Objekte.

Wenn Sie Ihre Datenbank als Tabellen behandeln, um Ihre Objekte einfach in Zeilen zu halten (ein gängiger Ansatz) und der Anwendung direkten Zugriff auf Tabellen zu gewähren, geben Sie alle Vorteile der Definition einer Schnittstellenschicht von Datenbankdiensten auf, die die Datenbank zum Schutz verwenden kann sein Umfang.

ORMs haben ihren Platz, aber wenn Sie sie verwenden, um Ihre Objekte einfach so zu erhalten, wie sie in Ihrem Objektmodell entworfen wurden, ist Ihre Datenbank keine relationale Datenbank, und sie kann nicht als eine für die Zwecke der ETL, Berichterstellung, verwendet werden. Refactoring usw.

Ich denke, die Logik hinter diesen Dingen ist, dass der Aufwand für das Erstellen und Ausführen einer SQL-Anweisung in der Framework-Schicht im Vergleich zum Aufwand in anderen Teilen des Systems unbedeutend ist (z. B. ist ein HTTP-Anforderungs-Roundtrip um Größenordnungen länger).

Die Vorteile - schnelle Entwicklung, Abfragen, die in die Sprache passen, anstatt maskierte Zeichenfolgen usw. zu sein, überwiegen häufig die Nachteile. Wenn die Leistung ein Problem darstellt, können Sie sie später optimieren.

Ich denke nicht, dass "SQL nicht kennen müssen" ein Faktor ist. Jeder anständige Entwickler muss SQL irgendwann in seiner Entwicklung kennen. Die Idee einer Datenbankabstraktionsschicht besteht darin, den Aufwand für die Generierung von Boilerplate-Code für Datenbankabfragen zu verringern.

In unserem System in Java habe ich ein Dienstprogramm zur Codegenerierung erstellt, das kommentierte Klassen verwendet, eine vollständige CRUD-API generiert und all die skurrilen Dinge behandelt, die Sie im Laufe der Zeit lernen. Es ist viel einfacher, ein Modell zu erstellen und mit Anmerkungen zu versehen, als ein DAO zu schreiben. Skalieren Sie ein solches Tool und Sie erhalten LINQ oder Hibernate oder unzählige andere ORM DB-Lösungen.

Hier gab es eine andere Frage zu ORMs im Allgemeinen. Schauen Sie sich das an, um mehr darüber zu diskutieren, ob die Impedanzfehlanpassung so wichtig ist oder nicht.

Ich denke, die wirkliche Lösung, die sie brauchten, war eher ein SQL-Literal. VB.Net 9.0 unterstützt XML-Literale , mit denen Sie XML direkt in Ihren Code schreiben und sicherstellen können, dass es validiert ist und der DTD entspricht. Eine ähnlich nette Funktion wären SQL-Literale, mit denen Sie Inline-SQL-Code in Ihren .NET-Code schreiben und von der IDE validieren lassen können. Es müsste eine Art Plugin-Architektur geben, um die Informationen anhand der Datenbank zu überprüfen, aber das könnte für die gängigen Datenbank-Engines leicht geschrieben werden. Dies würde meiner Meinung nach die wirkliche Lösung für das Problem darstellen, das sie zu lösen versuchten, ohne auf suboptimale Lösungen zurückzugreifen.

Codemonkey macht einen sehr guten Punkt: Gespeicherte Prozeduren bieten eine Abstraktionsebene, die einige der Versprechen der komplexeren ORM-Modelle erfüllt. Dies ist auf den ersten Blick nicht intuitiv, aber ich kann mir ein Beispiel direkt aus meinem eigenen Code vorstellen. Ich habe einen Check-in-Sproc, der fast ein Dutzend Tabellen berührt (wem gehört diese ID? Haben sie eine Mitgliedschaft? Gibt es Nachrichten? Erhalten sie Punkte für diesen Check-in? Usw.).

Dies in C # zu modellieren - egal wie ausgefeilt das Datenmodell ist - wäre niemals eine gute Idee, da es viele Fahrten "über den Draht" erfordern würde, um Daten zu überprüfen und verschiedene Tabellen zu aktualisieren. Zwar können Sie in Linq oder anderen ORMS mit Sprocs umgehen, ich benötige jedoch nur eine Wrapper-Klasse, mit der ich den Sproc mit Standard-C # -Parametern aufrufen kann. Tatsächlich war dies ein so dringendes Bedürfnis für mich, dass ich einen Codegenerator in T-SQL schrieb, um solche Wrapper zu erstellen.

Ich mag keine der aktuellen Lösungen - aber ich bevorzuge mehr Auswahlmöglichkeiten gegenüber weniger Auswahlmöglichkeiten ;-)

Ich habe vor langer Zeit ein OODBMS in einem Projekt verwendet, das der richtigen Lösung am nächsten kam (leider hatte das Produkt einige abscheuliche Fehler und schrecklichen technischen Support) - die Objektpersistenz war weitgehend unsichtbar , wurde hinter den Kulissen (über den Präprozessor-Codegenerator) gehandhabt und gesteuert durch sehr einfache Methoden zum Aktualisieren, Löschen und Suchen und einfache Container.

Ich würde dies gerne wieder sehen (und vielleicht macht es ein Objekt-Entitäts-Modell bereits gut), mit OCL (Object Constraint Language) als native Abfragesprache für mehrere Objekte

Ich muss zustimmen, dass der Ausbruch von ORM-Tools größtenteils auf den Ärger zurückzuführen ist, SQL zu schreiben, sich mit dem zu verwendenden DB-Treiber zu befassen, intern zwischen DBs zu abstrahieren (Oracle vs SQL Server, vs was auch immer für die Wiederverwendbarkeit von Code) und Datentypen zu transformieren .

Ideale Lösung? definitiv nicht! Ich denke jedoch, dass dies eine Iteration ist, um die Anwendung besser mit dem Datenspeicher zusammenzuführen. Schließlich ist es in den meisten Fällen praktisch nutzlos, eine Datenbank ohne Zugriffsanwendung in einer beliebigen Sprache zu haben. (Würden Sie wirklich jemals nur Oracle installieren und erwarten, dass alle Mitarbeiter direkt in SQLPlus arbeiten?)

Daher denke ich, dass sich der Datenspeicher und die Anwendung nur so zusammen bewegen, dass der Anwendungsentwickler einfacher mit dem Datenspeicher interagieren kann.

Insbesondere für .NET würde ich anstelle von Linq lieber eine integrierte Methode sehen, um eine Klassendefinition einer zugrunde liegenden Datenquelle einem zugrunde liegenden Datenspeicher zuzuordnen und alle Installationen einfach zum Laufen zu bringen.

Mit anderen Worten könnte ich einfach sagen "Employee.Name = 'Rally25rs';" und die Eigenschaft des Objekts würde sich ändern, und darunter würde es für den Datenspeicher selbst bestehen bleiben. Lassen Sie SQL einfach komplett hinter sich, anstatt wie jetzt von Linq zu SQL einen halben Weg zu gehen.

Natürlich wirft eine solche Lösung Probleme mit der Leistung, der Transaktionsabwicklung usw. auf.

Vielleicht muss das gesamte Konzept der Programmiersprache und der relationalen Datenbank überarbeitet und neu ausgerichtet werden? In ihrem Kern sind sie völlig getrennte und unzusammenhängende Einheiten. Vielleicht ist es an der Zeit, einfach die "relationale SQL-fähige Datenbank" loszuwerden und das nächste zu erstellen, wenn die Ausführung einer Codezeile direkt auf die Datenbank angewendet wird.

Es gibt kein Problem mit Linq, aber mit denen, die es verwenden und ignorieren, was "hinter den Kulissen" passiert.

Ich ziehe es immer noch vor, mir mit SQL die Hände schmutzig zu machen. Zumindest weiß ich genau, was passiert.

Ted Neward schrieb einen großartigen Aufsatz über seine Sicht auf dieses Thema - dass ORMs das "Vietnam" der Informatik sind ...

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Die meisten Leute haben einen wesentlichen Punkt übersehen: In den meisten Fällen sind Sie beim Abfragen in LINQ wesentlich produktiver als in SQL. Ich habe einen Artikel darüber geschrieben, warum das so ist.

Als ich die LINQPad-Herausforderung festlegte, machte ich keine Witze: Ich mache fast alle meine Ad-hoc-Abfragen in LINQ, da die meisten Abfragen in LINQ schneller und zuverlässiger geschrieben werden können als in SQL. Ich habe auch große Geschäftsanwendungen mit LINQ to SQL entworfen und bearbeitet und dabei erhebliche Produktivitätssteigerungen festgestellt. Dies ist kein "Architektur-Astronaut" - LINQ to SQL ist eine produktive und praktische Technologie, die genau diese Site antreibt .

Das größte Hindernis bei LINQ ist, es nicht richtig zu lernen. Ich habe so viele LINQ-Abfragen gesehen, die schreckliche Transliterationen von SQL-Abfragen sind, um dies zu sichern. Wenn Sie LINQ-Abfragen nur mit Ihren SQL-Kenntnissen schreiben, kann das Endergebnis nur das gleiche oder schlechtere sein als SQL.

Ich habe gerade diese Frage entdeckt. Ich denke, es ist mittlerweile ziemlich gut gespielt, aber ich werde trotzdem meine zwei Cent einwerfen ...

Ich möchte nur Code für die Dinge schreiben, die nicht offensichtlich sind.

CRUD-Code ist offensichtlich. Ich will es nicht schreiben. Daher sind ORMs eine gute Idee.

Dies bedeutet nicht, dass ORMs keine Probleme haben, aber die Probleme liegen in der Ausführung, nicht in der Absicht. Mit zunehmender Reife der ORMs werden sich die Probleme verringern, und die bereits für einfache Szenarien verfügbaren Produktivitätsgewinne werden sich schließlich auch auf komplexe Szenarien erstrecken.

LINQ ist auch eine gute Idee. Andere haben eine Reihe von Vorteilen erwähnt, aber ich muss nur an das erste Mal denken, als ich versuchte, einen Pivot in LINQ durchzuführen, bei dem ich die Anzahl der Spalten im Voraus nicht kannte. Oder als ich zum ersten Mal merkte, dass ich nicht DataViewjedes Mal ein neues erstellen musste, wenn ich etwas sortieren oder filtern wollte. Mit LINQ kann ich alles tun, was ich mit Daten in C # tun möchte, anstatt herausfinden zu müssen, wie die Arbeit zwischen SQL und C # aufgeteilt wird.

Ja, ORMs, LINQ und andere aufkommende Technologien sind suboptimale Lösungen, aber sie verpassen nicht den Punkt und werden nicht für immer suboptimal sein.

Ich wollte dies als Antwort auf die Antwort von @SquareCog hier schreiben , aber es sagte mir, dass ich noch -1836 Zeichen übrig hatte. SO noob hier also entschuldige mich, wenn ich das falsch gemacht habe.

Im 18. Jahrhundert studierte der Gentleman der Freizeit Naturwissenschaften. Zu dieser Zeit war die Wissenschaft in ihrer Gesamtheit kein so großes Thema, dass ein einigermaßen intelligenter Mensch nicht alles verstehen konnte. Damit meine ich, dass ein einzelner Gelehrter das gesamte wissenschaftliche Denken der Zeit verstehen könnte.

Im Laufe der Zeit wurden Hunderte neuer Wissenschaftsbereiche entdeckt und jeder so weit erforscht, dass heutzutage nur noch sehr wenige Menschen die Gesamtheit eines einzigen vollständigen Wissenschaftsbereichs verstehen können.

So ist es auch mit der Programmierung.

Heutzutage ist das Programmiersprachenfeld groß genug und wächst schnell genug, so dass es vernünftigerweise von einem Entwickler erwartet werden kann, die Gesamtheit seiner eigenen Fachsprachen zu kennen. Dass von einem erfahrenen Codierer erwartet werden kann, dass er auch das gesamte Datenbankfeld versteht, einschließlich des Datenbankdesigns, der Nuancen von nativem SQL und dessen Funktionsweise in verschiedenen Datenbanken sowie der Verwaltung dieser Datenbanken, ist möglicherweise ein wenig erforderlich.

Ich denke, einige der Antwortenden hier beschönigen einige der Komplexitäten bei der Entwicklung einer großen Datenbank mit leistungsfähiger Unternehmensebene, da das Wissen, dass eine Handvoll SQL-Anweisungen dies mit Sicherheit nicht schafft. Aus diesem Grund haben die meisten großen Softwarehäuser engagierte Teams von Datenbankentwicklern. Wie Stroustrup sagt, ist "Teilen und Erobern" der einzige Weg, um die Komplexität bei der Entwicklung und Verwaltung großer Softwareprojekte effektiv zu bewältigen.

Entwickler mögen es nicht, mit SQL zu arbeiten, weil sie faul sind oder weil sie sich dadurch icky fühlen. Sie arbeiten nicht gern mit SQL, weil sie klug sind. Sie wissen besser als jeder andere, dass nur jemand, der sich auf SQL spezialisiert hat, die höchste Datenbankfunktionalität bietet und dass es eine suboptimale Entwicklungsstrategie ist, wenn sie in die Lage versetzt werden, "Alleskönner" -Entwickler zu sein.