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

68

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.

Mark Brittingham
quelle
Ich habe die gleiche Verbindung zu "Leaky Abstractions" hergestellt. All diese Komplexität des Versuchs, eine Reihe von Größen und Formen von Listen für beide Seiten zugänglich zu machen, scheint darauf abzielen, diesem Prinzip auf Kosten der Einfachheit und Kohärenz zu trotzen. LINQ-to-SQL ist ein erstklassiges Beispiel.
Dkretz
Sehr gute Frage. Ich erinnere mich, wie ich einen MS-Mann bei einem TechDays gefragt habe, wohin MS unterwegs ist, zwischen Linq, Entities usw. Er schien es auch nicht zu wissen ...
Benjol
Benjol - danke. Ich war sehr zufrieden mit der Antwort auf diese Frage. Ich mache mir Sorgen, dass viele der MS-Technologien aus dem Bedürfnis hervorgehen, etwas Großes zu tun, anstatt sich auf die Fußgängerbedürfnisse der Entwickler zu konzentrieren. Wenn etwas Großes funktioniert - wie .NET - dann wissen wir es natürlich alle zu schätzen. Aber LINQ macht das nicht für mich. Ich denke, wir wären besser mit einem einfacheren und unkomplizierteren Tool bedient.
Mark Brittingham
2
Mark, aus der Antwort, die Sie gewählt haben, und Ihren Kommentaren ist klar, dass dies keine Frage ist, sondern eine Stellungnahme. Klebe es auf dein Blog.
mcintyre321
2
mcintyre - wovon redest du? Dies war eine enorm beliebte Frage, die viele Debatten und Diskussionen ausgelöst hat (wie Benjol sagt: "Sehr gute Frage"). Nach allem, was ich sagen kann, haben einige Leute etwas daraus gelernt, auch wenn sie mit meiner gewählten "Antwort" nicht einverstanden sind. Meiner Ansicht nach ist SO ein Ort, an dem man das gesamte Gebiet der Softwareentwicklung erkunden kann, und ich habe eine Menge Arbeit geleistet, um das Wachstum in diese Richtung zu unterstützen. Der einzige wirkliche Nachteil von SO ist, dass es eine übermäßige Anzahl von Menschen gibt, die es für angemessen halten, unhöflich zu sein, wenn sie mit jemandem nicht einverstanden sind.
Mark Brittingham

Antworten:

18

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.

Otávio Décio
quelle
4
Ich habe das gleiche getan. Für alles Komplexere, das eine einzelne Zeile auswählt / aktualisiert / löscht, möchten Sie wahrscheinlich trotzdem benutzerdefiniertes SQL schreiben, sodass ich keine Notwendigkeit für etwas wie Linq sehe.
Kibbee
@ Kibbee - genau. Aus diesem Grund habe ich in meinem DAL ein "out", um SPs oder benutzerdefiniertes SQL aufzurufen und die Ergebnisse in DTOs zu speichern, und ich kann auch good'ol DataSets zurückgeben, wenn ich Lust dazu habe.
Otávio Décio
1
Es sollte selbstverständlich sein, dass LINQ eine weitere Abstraktionsschicht ist; aber es ist eins zu viel. Es löst kein bekanntes Abstraktionsproblem. Wenn dies der Fall wäre, würde eines verschwinden. Aber dafür gibt es hier keinen Kandidaten.
Dkretz
2
Ich habe nicht versucht, das Abstraktionsproblem zu lösen - ich wollte es nur einfacher machen, SQL-Abfragen in Objekte und Objekte zurück in die Datenbank zu verwandeln, so einfach ist das. Es hat meine Entwicklungszeit verkürzt, meine Codequalität insgesamt erhöht und genau das habe ich gesucht.
Otávio Décio
2
@ Jeff - Sie können es als databaseroker.codeplex.com finden. Ich habe es dort abgelegt , um es an einem zentralen Ort zu haben. Bitte zögern Sie nicht, es zu überprüfen und mich (über die Kontaktseite) zu informieren, wenn Sie Fragen / Vorschläge / Kritik haben, alle willkommen.
Otávio Décio
45

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.

SquareCog
quelle
Zumindest glücklicher, was immerhin oberste Priorität hat.
Dkretz
7
Ich konnte nicht mehr widersprechen. SQL ist einfach. Es gibt nur eine Handvoll Schlüsselwörter, die Sie kennen müssen. Gut geschriebenes, performantes SQL kann die App messbar beschleunigen. Schlecht geschriebenes SQL kann das RDBMS und die Website in die Knie zwingen. Wenn Sie kein SQL schreiben möchten, sagen Sie es einfach.
DOK
1
Sie predigen dem Chor, DOK. Ich sage nur, dass es auch außerhalb der Kirche Musik gibt :-)
SquareCog
13
Das ist wirklich traurig: Der Umgang mit Daten ist für eine gute Programmierung von zentraler Bedeutung. SQL nicht zu beherrschen ist wie sich für einen Gitarristen zu entscheiden, aber Akkorde nicht zu mögen.
Mark Brittingham
2
Das habe ich erraten. Ich bin Entwickler und ich liebe SQL. Aber ich denke das ist nicht üblich.
Jeff Davis
36

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.

Jim Anderson
quelle
1
Jim, ich denke du hast absolut recht. Die Frage ist, ob der derzeitige Ansatz für den Umgang mit diesem Schmerz übertrieben ist. Ich habe das nicht gesagt, aber ich habe begonnen, einen Codegenerator zu entwickeln, um Klassen um SQL-Abfragen für meinen eigenen Gebrauch zu erstellen. Linq / SubSonic funktionieren bei mir einfach nicht.
Mark Brittingham
Auf jeden Fall wahr. Ich habe die Arbeit an Nebenprojekten vollständig eingestellt, als ich zur Datenschicht kam, und festgestellt, dass es an der Zeit ist, immer wieder 200 SQL-Abfragen für alle meine Objekte zu schreiben. Ein ORM-Tool würde dies dramatisch beschleunigen. Leider saugen die meisten ORM-Tools :(
CodingWithSpike
Ich denke, es ist eine persönliche Entscheidung. Sie können jederzeit Ihre eigene Datenzugriffsschicht schreiben, wie wir es vor der Popularität von ORMs getan haben, und haben die volle Kontrolle, aber die ORMs bieten normalerweise den Rahmen für eine akzeptable DAL (auch mit ihren Fehlern), um viel Zeit und Arbeit zu sparen.
Jim Anderson
1
"viel Zeit und Arbeit sparen" ist die operative zweifelhafte Behauptung. Es ist nicht meine subjektive Erfahrung, aber ich nehme dein Wort dafür, dass es deine ist. Ich halte DALs nicht für besonders schwierig oder langweilig, es sei denn, Sie verschwenden Zeit damit, CRUD-Vorlagen zu
erstellen
@le dorifier: Ja, ich denke dein Kilometerstand kann variieren. Angesichts der Zeit, die für die Erstellung von Produkten wie Hibernate und Entity Framework aufgewendet wurde, würde ich hoffen, dass sie einen Mehrwert bieten und den erforderlichen Daten-Installationscode reduzieren.
Jim Anderson
12

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.

Frederik Gheysels
quelle
3
Ich bin im selben Boot. Crud SQL zu schreiben ist einfach. Es geht darum, nicht die Installation / den Kleber schreiben und neu schreiben zu müssen, mit denen die Abbildung der beiden Welten verwaltet wird. Dieser Teil ist schwer konsequent zu machen, besonders im Team mit vielen Entwicklern. Mit einem ORM-Mapper kann jeder es vergessen und alles einheitlich erledigen.
Daniel Auger
10

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/

Trevor Abell
quelle
9

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.

Cristian Libardo
quelle
1
Dann müssen wir einen Datenspeicher erfinden und implementieren, der dem Objektparadigma entspricht, anstatt SQL zwangsweise anzupassen. Sie verschieben nur die Impedanzfehlanpassung auf die andere Seite der Schnittstelle.
dkretz
3
"Hör auf, dir Sorgen zu machen" ist eine schreckliche Art, in dieser Branche zu leben. "alles in Frage stellen" ist viel besser.
CodingWithSpike
Auch Abstraktion ist nicht immer gut. Dies führt zur Verwendung der gemeinsamen Bits zwischen Werkzeugen und zu keiner Spezialisierung. Beispiel: Zusammenfassung zu "DB" und Sie müssen die fortlaufende Benachrichtigung von Oracle und sogar gespeicherte Prozesse entfernen, da diese nicht in allen DBs vorhanden sind.
CodingWithSpike
@ledorfier: Ich kann in der Praxis sehr gut zustimmen, in der Praxis ORMs Arbeit sehr gut , es wird immer die "anderen" 5% geben
Cristian Libardo
@le dorfier: Ich stimme nicht zu. :) Das Beziehungsmodell ist ein gutes Modell zum effizienten Speichern von Daten. Mit dem relationalen Modell können Sie auch problemlos Berichte usw. erstellen. (Verwenden Sie hierfür also kein OR / M.) OO ist jedoch eine gute Möglichkeit, ein Domänenmodell darzustellen, sodass beide Modelle zusammenarbeiten müssen.
Frederik Gheysels
9

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?

dkretz
quelle
1
Ich stimme mit allem überein, was Sie sagen, außer dem "einfach muss". Seien Sie ehrlich - Sie und ich sind C-Hacker in einer Java-Welt. Unsere Sachen mögen effizienter laufen, aber je schneller wir den Status Quo akzeptieren, desto niedriger wird unser Blutdruck sein :-).
SquareCog
4
Ganz im Gegenteil - die meisten Abfragen werden in LINQ einfacher . Das Problem ist , dass viele Menschen LINQ richtig lernen scheitern und damit sie ihre transkribieren ihre SQL - Abfragen in LINQ - und natürlich dann können Sie nur verlieren und nie gewinnen.
Joe Albahari
Ich bin froh, dass es für Sie "einfacher" wird. Für mich bedeutet es, etwas Einfaches zu nehmen und es in etwas anderes zu übersetzen, was unbestreitbar die Komplexität erhöht. Und nichts ist immer perfekt abgebildet.
Dkretz
@ Gurdas Nijor Ja. Deklarativ == Genial. :)
Jeff Davis
7

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.

ansgri
quelle
6

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.

dkretz
quelle
Ich habe QBE tatsächlich verwendet, da es Anfang der 90er Jahre im Datenverwaltungstool "Paradox" implementiert wurde, also erinnere ich mich! Ihre Analogie zu "Ein Ring, um sie alle zu regieren" war von unschätzbarem Wert!
Mark Brittingham
Ich denke, die Analogie ist Mist. LINQ ist ein Versuch, die Impedanzfehlanpassung zu beheben, nicht eine andere relationale Abfragesprache.
Reinierpost
QUEL war die ursprüngliche Abfragesprache von Berkeley's Ingres und nicht zu verschieden von SQL, was es schnell verdrängte. QBE war eine grafische / textuelle Benutzeroberfläche, die über SQL stand: Es war ziemlich ordentlich für einfachere Abfragen, aber nicht so gut für wirklich komplexe Dinge . Ich denke auch nicht, dass SQL eine große Herausforderung darstellt. SQL war eine äußerst leistungsfähige und ausdrucksstarke Sprache.
Jim Ferrans
5

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.

Isaac Dealey
quelle
5

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/


quelle
4

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.

codemonkey
quelle
4

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.

Cade Roux
quelle
3

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.

JeeBee
quelle
Für eine einzelne Anfrage können jedoch leicht 10 oder sogar 100 Anfragen gestellt werden. Die Tatsache, dass die http-Anforderung eine Größenordnung länger ist, wird durch die Tatsache umgangen, dass Sie Abfrageoperationen in einer Größenordnung oder mehr ausführen.
Kibbee
Ja, hier fällt die Logik ins Wanken - ernsthafte Web-Apps, die im Hintergrund so viel SQL ausführen, müssen wirklich optimiert werden, um die Verlangsamung der Abstraktion zu beseitigen. Aber für eine einfache Standardanwendung auf Intranetform? Anfangs kann es die zeitsparende Abstraktion verwenden, bis es aufbläht;)
JeeBee
3

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.

Hamish Smith
quelle
3

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.

Kibbee
quelle
3

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.

Mark Brittingham
quelle
Das Modellieren in C # ist eine gute Idee, da Sie damit Vererbung, Modularität und Unit-Tests verwenden können. Kabelauslösungen sind im Allgemeinen kein Problem - weniger ein Problem als die Wartung einer mäßig komplexen gespeicherten Prozedur - und Sie können sogar keine Komponententests durchführen, ohne die Datenbank einzurichten.
Andrey Shchekin
Ja, aber ORMs oder DALs bieten normalerweise eine allgemeinere (DB-agnostische) Lösung, während Sprocs (sofern Ihre DB sie unterstützt) DB-spezifisch sind.
Jim Anderson
3
Ich habe hier immer diese DB-agnostische Regel. Aber wie viele Leute wechseln wirklich die Datenbank, wenn die Anwendung vollständig entwickelt ist?
Donny V.
@Andrey: In gespeicherten Prozedursprachen wie PL / SQL können Sie auch Vererbung, Modularität und Unit-Tests verwenden. Check out download-uk.oracle.com/docs/cd/A91202_01/901_doc/appdev.901/… @Jim: Wenn Sie C # /. NET verwenden, können Sie nur auf einer einzigen Plattform (Windows) bereitstellen. Wenn Sie gespeicherte Prozeduren in PL / SQL schreiben, können Sie sie auf jedem von Oracle unterstützten Betriebssystem bereitstellen. Mit anderen Worten, PL / SQL ist wie Java: "Einmal schreiben, überall ausführen", nur dass es eine viel bessere Leistung als Java erbringt!
ObiWanKenobi
3

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

Steven A. Lowe
quelle
2

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.

CodingWithSpike
quelle
ODBC / JDBC (und ihr Spawn) haben zufriedenstellende Arbeit geleistet, um Unterschiede in der SQL-Implementierung von DBMS zu beseitigen. Beachten Sie jedoch, wie selten sie mehr verwendet werden. Alle Beiträge mit proprietären Syntaxproblemen anzeigen. Die Antwort darauf liegt seit Jahren vor - zunehmend ignoriert.
dkretz
@le dorfier: guter Punkt. Vielleicht liegt ein Teil des Problems darin, dass die Abstraktion jede Spezialisierung beseitigt? Beispiel: Wenn ich den Oracle-Treiber nicht verwende, kann ich die Tools für die kontinuierliche Benachrichtigung nicht verwenden. Vielleicht ist ODBC der Ganzjahresreifen (überhaupt mittelmäßig), während spezialisierte Fahrer die Rennreifen sind?
CodingWithSpike
1

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.

DonOctavioDelFlores
quelle
1

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

Flaumknochen
quelle
Fuzzbone - Der Artikel verbringt etwas zu viel Zeit damit, den Vietnamkrieg zu überprüfen, aber er ist genau richtig. Das ist eine hervorragende Referenz ... danke!
Mark Brittingham
1

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.

Joe Albahari
quelle
Albahari - danke für den Kommentar. Ich habe keinen Zweifel daran, dass viele LINQ-Abfragen schlecht ausgeführt werden. Jetzt werde ich sagen, dass es einige Überzeugungsarbeit braucht, aber ich werde Ihr Argument RE lesen: die Produktivität von LINQ. Ich persönlich finde SQL unglaublich effektiv und produktiv! Nochmals vielen Dank ... guter Kommentar.
Mark Brittingham
Können Sie ein gutes Beispiel für eine LINQ-Abfrage geben, die eindeutig eine Transliteration von SQL war und die Sie effizienter hätten schreiben können? Können Sie etwas überzeugenderes zeigen als nur Assoziationen und Parametrisierung, die eher geringfügig sind?
Timwi
1
Hier ist ein einfaches Beispiel: social.msdn.microsoft.com/Forums/en-US/linqprojectgeneral/…
Joe Albahari
1

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.

Devuxer
quelle
+1 - Gute Kommentare - insbesondere die Beobachtung, dass "ich nur Code für die Dinge schreiben möchte, die nicht offensichtlich sind." Denken Sie daran, dass ich nicht generell gegen DALs argumentiere (tatsächlich habe ich im Laufe der Jahre drei ORM-ähnliche DALs gebaut). Ich behaupte, dass ein guter DAL nicht das gesamte Architektur-Astronauten-Zeug benötigt, das MS in Linq to Entities steckt: Die Automatisierung der langwierigen Aspekte von SQL und die Reduzierung der Impedanzfehlanpassung zwischen SQL- und C # -Datenstrukturen ist alles, was Sie brauchen - es ist die optimale Lösung. Jeder Vorteil, den Sie L2S beschreiben, kann zu weitaus geringeren Kosten erzielt werden!
Mark Brittingham
@Mark, ich habe gerade SqlMetal (den Befehlszeilen-LinqToSql-Generator) für ein relativ einfaches SQL Server Express-Datenbankprojekt verwendet und es einfach geliebt. Es funktioniert einfach. Ich habe keine Kosten erlebt. Was LinqToEntities betrifft, kann ich noch keinen Kommentar abgeben, da ich dies aufgrund all der gemeldeten Probleme mit "Generation 1" vermieden habe. Sobald ich auf Visual Studio 2010 aktualisiert habe, werde ich den neuen LinqToEntities auf jeden Fall einen Blick geben. Ich habe immer gedacht, dass es nur LinqToSql für Steroide ist, aber vielleicht ist der Unterschied grundlegender.
Devuxer
Ich halte auf jeden Fall meine Augen offen, daher ist es gut, von Ihren Erfahrungen zu hören. RE: SqlMetal. Erstens - Sie werden VS 2010 lieben. Ich benutze die Beta seit ungefähr 4 Monaten und es ist ein enormes Upgrade. WRT LinqToEntites, es ist ein ganz anderes Tier als LinqToSql. Weißt du, wenn MS sich damit zufrieden gegeben hätte, bei LinqToSql zu bleiben, hätte ich mich wahrscheinlich nicht so gut geschlagen, wie es mir wirklich gefällt. Aber L2Sql wird veraltet und L2E als Weg nach vorne positioniert, und ich denke nur, dass das ein Fehler ist. Wenn Sie es versuchen und eine andere Einstellung haben, würde ich gerne hören, warum.
Mark Brittingham
Hmmm ... Vielleicht hätte ich den Titel "Verpasst Linq to Entities nicht den Punkt?"
Mark Brittingham
@Mark: Wenn LinqToEntities mich aus meiner Sicht nicht nur auf eine Datenbank verweisen lässt und den gesamten Code, der für die Interaktion mit dieser Datenbank erforderlich ist, automatisch generiert, ist dies für mich definitiv ein Rückschritt. Ich möchte ein Tool, das mir das Programmieren erleichtert und es mir ermöglicht, mich auf die Dinge zu konzentrieren, die für meine spezielle Anwendung einzigartig sind. Was Ihren Titel betrifft, so war Ihre Frage im Nachhinein vielleicht eher L2E als L2S, aber so oder so hat sie viele interessante Antworten und Diskussionen hervorgebracht.
Devuxer
0

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.

Neutrino
quelle