Ich habe einen Code-Generator geschrieben, der POCOs und Repositories für eine bestimmte SQL Server / CE-Datenbank generiert. Nichts Besonderes, nur einfache CRUD-Prozeduren mit klassischem ADO.Net. Meine Frage ist, warum sollte ich ein ORM wie L2S / EF4 über benutzerdefinierten Code-Generator verwenden? Alle 2 oder 3 Jahre liefert Microsoft ein neues Datenzugriffs-Framework / Technologie und ich kenne ziemlich viele Entwickler, die nicht immer in Kontakt mit den neuesten Technologien sein können, aber jeder von ihnen kennt das klassische ADO.Net, wie man das ändert bestehender Code und wie man neue Funktionalitäten entwickelt. Bringen ORM-Tools etwas mit, was heutzutage ein Muss ist, oder kann ich bei einem klassischen ADO.Net bleiben?
Danke!
Es hängt wirklich von Ihren Projektanforderungen und Ihrem Entwicklungsprozess ab. ORMs sind mit einer Menge Whizz gepackt und bringen viel Freude auf den Tisch, aber wenn Sie nur ein paar verschiedene Funktionen kaufen, finden Sie möglicherweise die erforderliche geistige / körperliche Crud enttäuschend.
Zunächst sollten Sie wissen, dass es zwei Arten von ORMs gibt: solche, die ein vorhandenes Schema der Anwendungslogik zuordnen (Sie verwalten das Schema) und solche, die Anwendungslogik einem Schema zuordnen (das ORM verwaltet das Schema). Sie sollten vorzugsweise die erste Art vermeiden, da sie Sie nicht davon abhalten, eine beträchtliche DBA-Arbeit für jede Umgebung zu tun / zu wiederholen, dh Sie müssen sicherstellen, dass alle Entwickler ein geeignetes Schema ausführen, zusätzlich dazu, dass sie Außerdem wird entsprechender Code ausgeführt. Die zweite Art kann völlig abstrahieren, dass Sie überhaupt eine zugrunde liegende Datenbank verwenden, damit Sie sich ausschließlich auf die Anwendungsdomäne konzentrieren können, was Entwickler glücklich macht.
Kein DBA, keine lokalen Entwicklungsbemühungen gegen eine nicht mehr handhabbare Remote-DB-Instanz, keine Cross-RDBMS-Nuancen mehr, keine gespeicherten Prozeduren, keine Abfragen mehr mit fest codierten Referenzen, keine komplexeren SQL-Migrationsabfragen mehr.
Also sollte Ihr ORM idealerweise:
Andere nette Zucker:
Denken Sie daran, dass Sie jedes Projekt mit einem ORM wie @Noon starten können, aber Sie können nicht jedes Projekt jetzt ohne es starten. Im Idealfall eignen sich ORMs hervorragend für Projekte, bei denen die Entwickler die volle Kontrolle haben oder für die Ausführung privater, lokaler DB-Instanzen benötigt werden. Wie auch immer, es ist ein riesiger Sprung von der Ass-Rückwärts-Methode: eine Anfrage an DBA stellen, Kaffee trinken bis die DB aktualisiert wird, hoffe, dass es innerhalb der Woche passiert.
Ich ging zur Webprogrammierung, mit den neueren Sprachen, die nicht die richtige Datenverarbeitung haben (was zu dem wahrgenommenen Bedarf an ORM führt), während ich gleichzeitig meinen All-End-All-Code-Generator baute. Hab noch nie zurückgeschaut.
Ein Grund, warum ich ein ORM niemals in Betracht ziehen würde, ist, dass ich tatsächlich weiß, wie Datenbanken funktionieren, sehr gut, danke. Ich versuche nicht, es so aussehen zu lassen, als würde ich keine relationale Datenbank benutzen. Ich möchte etwas, das mir die Macht der Datenbank mit so wenig Arbeit wie möglich bringt - und das wird niemals ein ORM sein, denn das ist es nicht was sie sind.
Nach meiner Erfahrung ist ein guter wörterbuchbasierter Generator die beste DRY-Programmierung (Wiederhole dich nicht), er kann mich von der Arbeit mit der DB befreien und mir erlauben, mich auf das Wesentliche zu konzentrieren, gute biz Logik auf einem soliden Tischdesign geschrieben.
BEARBEITEN : Zwei weitere Punkte:
1) Eine Nicht-ORM-Route ist, wenn nichts anderes, einsam , da ORM so sehr die Wut ist, dass es schwer ist, die Leute zu finden, die sie nie gebraucht haben und nicht sehen die Stelle. Aber lass dich von deinem technischen Urteil leiten.
2) Vor ein paar Jahren habe ich einen Blogeintrag geschrieben, "Warum ich ORM nicht verwende", auf den ich nicht verlinken werde, weil es zu aufdringlich ist. Nach einiger Zeit versuchte ich erneut, den Sinn dafür zu erfassen, warum es möglich ist, ORM objektiv zu betrachten und keinen Wert zu sehen, ohne aufdringlich zu sein, und dieser Link lautet: Ссылка
Hängt davon ab; Magst du es, nutzloses busywork mit der Datenbank zu tun, oder würdest du es vorziehen, alles zu generieren?
Aber ernsthaft, für mich gibt es absolut keine Frage. Jedes bekannte Projekt sollte mit einem ORM beginnen, und für mich ist LLBLG das beste. Es ist jedoch nicht frei. Aber es spart so viel Zeit bei der Entwicklung der Datenschicht und bietet eine schöne Struktur zum Arbeiten.
Es ist wirklich eine Frage der Entscheidung, wie Sie Zeit verbringen wollen. Wenn Sie bei der Arbeit in der Datenschicht einen Wert sehen, aus einer Reihe von Gründen, die Sie rechtfertigen können, wenn Sie gegen etwas wie LLBLGen abgewogen werden, dann tun Sie es. Aber für mich nicht.
Natürlich stimme ich dir zu, ständig ORMs zu ändern ist nicht ideal. Also schlage ich vor, dass Sie ein wenig Zeit (vielleicht ein paar Wochen) damit verbringen, herauszufinden, welcher der beste für den Stil ist, in dem Sie sich entwickeln möchten, und wie Sie Ihre Projekte strukturieren und dann darauf eingehen. Die meisten Hauptwege werden heutzutage sowieso sehr gut unterstützt, so dass Sie nicht davor zurückschrecken könnten, eines davon zu wählen und es zu standardisieren.
Ein Pluspunkt für ein ORM ist die Überprüfung der Kompilierzeit. Ich werde das Entity-Framework als Beispiel verwenden, da ich das als ORM verwende.
Wenn Sie während der Entwicklung ein Datenbankschema ändern müssen (entfernen Sie eine Spalte, Tabelle usw.), aktualisieren Sie Ihr Modell von der Datenbank und kompilieren es anschließend. Überall, wo diese Spalte oder Tabelle referenziert wurde, erscheint jetzt ein Kompilierzeitfehler, der das Auffinden von Fehlern erleichtert, die wahrscheinlich nur zur Laufzeit mit dem Standard ado.net auffallen würden.
Eine andere Sache, über die Sie nachdenken sollten, sind Ad-hoc-Abfragen - was ist, wenn Sie nur ein paar Datenspalten aus einer Tabelle zurückziehen wollen? Mit generiertem Code müssen Sie eine neue Abfrage hinzufügen, eine Klasse, die mit Daten gefüllt werden soll. Mit einem ORM können Sie so etwas tun, wo eine anonyme Klasse für Sie generiert wird, so dass Sie das busywork nicht durchlaufen müssen einen selbst zu erschaffen.
Im Wesentlichen behandelt ein ORM alle Randfälle, die eine selbst gezüchtete Lösung normalerweise nicht aufweist.
%Vor%Für einfache CRUD und wenn Objekte eine Tabellencode-Generatoren darstellen, bringen Sie Sie direkt zu Ihrem Ziel. ORMs werden immer interessanter, wenn
Kurz gesagt: Wenn Sie nur eine einfache Zuordnung zwischen einer Tabelle und einem Objekt benötigen, können ORMs nützlich sein. Daher müssen Sie die Feature-Liste des ORM überprüfen und sich fragen, ob Sie es brauchen.
Es gibt eine Alternative zwischen einem Code-Generator und einem vollständigen ORM: Data Mapper (wie zB MyBatis ) bekannt als iBatis).
Tags und Links code-generation orm ado.net