Frage
Ich arbeite daran, den gesamten Datenzugriff mit Dapper zu implementieren. Meine erste Idee war, Repository-Muster mit Dapper zu implementieren. von: http://www.bradoncode.com/blog/2012/12/creating-data-repository-using-dapper.html
Dann habe ich linq Ausdruck zum Dapper Sqlbuilder hinzugefügt, um SQL zu minimieren, wie im Beispiel (dynamische Abfrage). So konnte ich etwas schreiben
sqlbuilder.Where(c=>c.Id == 1) or c.Id = myVar
Und jetzt frage ich mich, ob es eine gute Idee wäre, einen DbContext Like und DbSet zu implementieren und linq Ausdruck zu verwenden.
Die Frage ist nicht, ein vollständiges dbset oder dbcontext zu implementieren. Aber nur etwas, das aussieht (ohne die ganze Komplexität).
Nur ein DbContext, der Verbindung initialisiert und mehrere DbSet, die Tabellen mit Dapper abfragt, und eine Implementierung von iqueryable, um SQL basierend auf dem gegebenen Linkausdruck mit Hilfe von dapper sqlbuilder zu generieren.
Nach dem Lesen einiger Code-Teile und dem Vergleich mit dem Entity-Framework denke ich, dass es Zeitverschwendung ist, weil Entity Framework es bereits tut. Aber mit Dapper haben Sie die gesamte Kontrolle über die generierte SQL und es würde immer die gleiche Vorlage verwenden.
Bevor ich anfange (um meine Zeit zu verschwenden) würde ich gerne wissen ob es eine gute Idee ist oder nicht.
Edit: viele Kommentare sagen, dass SqlBuider keine gute Sache ist, warum ist es dann im Dapper-Projekt verfügbar?
Akzeptierte Antwort
Persönlich würde ich sagen, dass es etwas ist, was außerhalb des Kerns dessen liegt, was die feine Bibliothek zu bieten versucht. Es gibt einen Verdienst in der Idee, aber ich mache mir Sorgen, dass Sie LINQ-to-SQL im Grunde nur wieder implementiert haben, wenn Sie das getan haben. Es gibt einen einfacheren Weg dazu: Sie verwenden nur LINQ-to-SQL . Dapper ist in der Regel sehr glücklich, L2S-Modelle zu füllen - das ist im Wesentlichen, wie wir (die dapper-Autoren) es verwendeten (und es weiterhin verwenden), gegen unsere bereits bestehende L2S-Codebasis. Es wäre auch ähnlich wie EF usw.
Allerdings, wenn Sie wirklich die Arbeit in, ich bin mir sicher, dass Sie eine Bibliothek oben auf dapper, die dies tun könnte schreiben können. Es scheint einfach eine Menge Arbeit zu sein, Dinge zu tun, die bereits existieren.
Beliebte Antwort
Ein Schlüsselmerkmal von Dapper ist die Leistung.
Dapper wurde erstellt, um Ergebnisse von SQL-Befehlen schnell auf Objekte abzubilden. Und definitiv nicht, um Entwicklern das Schreiben von SQL zu ersparen. Es ist wahrscheinlich keine gute Idee, SQL Builder mit Dapper zu verwenden. Noch schlimmer ist die Implementierung der Änderungsverfolgung. Verwenden Sie einfach Entity Framework oder ein anderes vollständiges ORM, wenn Sie solche Funktionen benötigen.
Lizenziert unter: CC-BY-SA with attribution
Nicht verbunden mit Stack Overflow