Gibt es ein tool zum konvertieren von T-SQL-Gespeicherte Prozeduren in C#?
Update ab 2017:
Realistisch, die Antwort ist Nein, und selbst wenn es waren, die Sie sollten sehr vorsichtig sein mit der Verwendung.
Gibt es eigentlich nur zwei Wege für einen Angriff auf dieses problem:
a) in den sauren Apfel Beissen und konvertieren alles manuell und mühsam und mit einigen Methode der Verifikation, um zu überprüfen, dass alles weiterhin so Verhalten, als bestimmt, wie die Einheit/regression-tests. Verwenden Sie tools wie Linqer, wenn verfügbar, als Hilfe, zu lösen, ein Teil des Problems.
b) ganz von vorn Beginnen.
Es gibt keine option c), um etwas anderes handle, dass alles ordentlich und automatisch, und es könnten wohl nicht alle Fälle abdecken kann. Es gibt viele Dinge, die T-SQL machen kann, dass LINQ nicht (updates, inserts und deletes in den Sinn), und viele Dinge, die Sie würde besser tun, eine andere Art und Weise in C# (wie Cursor).
Sehr wenige Probleme wie diese erhalten ausgereifte, vollständige Lösungen, die vertraut werden kann, nicht zu regress-Funktionen (wie die kommerziellen VB6 zu VB.NET Wandler rechtfertigen könnte, dass die Ausgaben enorme Anstrengung, denn die schiere Menge der potenziellen Kunden gibt, und wo Sie abholen können ein Telefon oder einen Anwalt, wenn etwas schief geht), also wenn so ein tool existiert, sollten Sie extrem vorsichtig sein. Die übersetzung aus dem LINQ-kompatibel Teilmenge von SQL in LINQ ist ein eingegrenztes problem, das ist verständlich und ich denke, dass Linqer vertraut werden kann.
Dieser Frage wurde versucht, suss ein tool, das dabei helfen könnten, mit der option ein), aber ich kann mir vorstellen viele Leute, die dies Lesen suchen für option c). Es ist eine Teilmenge dieser Frage-und Antwort-das ist nicht eine schreckliche Idee, aber es funktioniert nicht automatisiert, entfernt die Verbleibende Belastung, da auch viele der einfachen gespeicherten Prozeduren haben mehr als Abfragen in einer LINQ-form ausdrückbar. Es war immer noch viel zu unhaltbar zu tun option a) für eines der Projekte, die ich erwähnt.
Ursprünglichen Frage folgt:
Ich habe ein paar Projekte, zu behaupten, dass eine Menge von gespeicherten Prozeduren von SQL Server (T-SQL). Ich weiß, wie Sie zu erhalten, aber da gibt es viele tools für die automatische Konvertierung zwischen den verschiedenen Sprachen, Frage ich mich, ob es irgendein tool zu konvertieren, die gespeicherte Prozeduren in C# - code?
Ich will NICHT, Sie zu bekehren, um CLR-Gespeicherte Prozeduren; ich möchte einfach migrieren, die Logik in meinen Daten-Ebene und der C# - das Ende von meinem Projekt und Automatisierung von Routinearbeit. Die meisten gespeicherten Prozeduren (vielleicht 70%?) sind einfach "SELECT * FROM Tabelle WHERE id = @id" Angelegenheiten, und Sie könnte getan werden, ebenso gut mit Entity Framework.
Ich weiß, dass es nicht eine gerade Linie zwischen T-SQL und C#, wie es ist von VB.NET zu C# und eine Konvertierung ist nicht so einfach; Sie müssen die Einführung eines Daten-Layers in C#, zum Beispiel, und einige Dinge wie Cursor nicht über entsprechende Konzepte. Ich will nur verschieben von gespeicherten Prozeduren, ohne repetitive manuelle Arbeit, wenn möglich.
Da dies wurde in Frage gestellt durch fehlerhafte Annahmen: ich weiß schon, T-SQL, und erhalten den code von einem dieser gespeicherten Prozeduren, ich könnte Ihnen sagen, was Sie tun. Es gibt sehr gute praktische Gründe, warum ich nicht wollen, dass die Logik weiterhin mit Wohnsitz in gespeicherten Prozeduren.
- Tun Sie das nicht... Nein.
- Schlechte Idee - T-SQL-gespeicherte Prozeduren sind leistungsstark und sind für eine Grund - verschieben in C# nicht geben Ihnen keine Vorteile - aber viele Nachteile. Tun Sie es nicht. Holen Sie verwendet, um T-SQL.
- Ich also meine Frage. Die gespeicherten Prozeduren meist nicht gespeicherte Prozeduren zu tun, was T-SQL nicht die besten, aber die gespeicherten Prozeduren für den Willen des seins gespeicherte Prozeduren, da tun einem einfachen, nackten WÄHLEN ist schlecht für die Seele. Bitte überdenken.
- Wenn Sie anfangen, das ist vielleicht eine andere Diskussion (Und ich bin sicher, es gibt viele threads hier über die Verwendung von Gespeicherten Prozeduren). Aber da Sie schon realisiert, dass die Art und Weise, bitte nicht, ändern Sie Sie, um C#.
- Ich denke, das ist eine berechtigte Frage. Es könnte momentan sein business Logik in stored procs, dass würde besser sein, bewegt sich in den application-layer; oder es könnte als Lernübung.
- So oder so, es gibt nichts, das wird konvertiert, wie gespeicherte Prozeduren, C#, ohne erheblichen manuellen Aufwand. Es funktioniert jetzt, aber Sie können nicht sicher sein, es wird die Arbeit später, und ich weiß nicht, wer das wollen würde, um zu Fuß die Kosten zu ändern, so viel und eigentlich nichts ändern.
- Chris: Genau. Ich weiß, für eine Tatsache, dass es nichts gibt, konnte nicht umgesetzt werden, ebenso durch ein Verfahren, das in einem Daten-layer-Klasse über die entsprechende LINQ-Anweisungen. Es ist nicht eine Lernübung. Ich kenne beide T-SQL und C# alle zu gut, und ich weiß einfach nicht arbeiten wollen, in T-SQL, es sei denn, ich mache etwas, das getan werden muss es (wie Cursor oder CTEs), weil die Wartbarkeit betrifft. Ich migrieren wollen, nicht halten Sie in sync, die ist, warum ich verstehe nicht ganz, Fosco Anliegen.
- Unabhängig davon, ob es eine gute Idee - und es gibt gute Argumente, die so oder so - es ist eine gute Frage zu Fragen, wie dies möglich sein könnte, unabhängig von dem Verdienst zu tun.
- Wartbarkeit?... T-SQL ist ein standard, der ist schon relativ konstant seit über einem Jahrzehnt, und C# wurde geboren und hat sich durch 4 Haupt-Versionen in dieser Zeit. Macht es Sinn, dass Sie nicht verstehen, mein Anliegen, als ich ganz sicher nicht, verstehen Sie. 🙂
- T-SQL wurde, wie viel von einem Schmerz in den Arsch zu arbeiten, wie ein Programmierer so lange, wie man es schon, richtig. Nur ein Scherz, meistens. Ich kann gar nicht so viel mehr, wenn es code in C# anstelle von T-SQL in gespeicherten Prozeduren.
- +1 @marc_s - Umgang mit T-SQL. Nicht bewegen-code um, nur weil Sie nicht so komfortabel in der Sprache. Sicher, dass C# kann mehr tun, als es ist eine Allzweck-Programmiersprache. Das heißt nicht, dass es das beste Werkzeug für jede Aufgabe. Halten data access in der Datenbank, wo es hingehört.
- Ich bin verwendet, um das arbeiten mit T-SQL. Der Zugriff auf Daten ist ein komplettes Chaos. Ich erbte diesen code und ich möchte in der Lage sein, den Sinn dahinter. Es ist die Besondere code, ich bin nicht komfortabel mit, nicht die Sprache. Ich werde genauso unwohl mit der Logik in C#, aber ich werde zumindest in der Lage, es zu beheben einfach mehr und mehr ausgereifte Werkzeuge zur Umgestaltung es. Ich werde tun, dass die harte Weise, die Konvertierung der gespeicherten Prozeduren zeilenweise, wenn ich muss, aber ich dachte, ich würde sehen, wenn gab es Möglichkeiten, die Automatisierung so weit wie möglich.
- Ich ermutige Sie zu uns kommen, dba.stackexchange.com und Fragen Sie die gleiche Frage, aber im Sinne von etwas neues zu lernen.
- Danke, aber ich konnte schon sagen, was jedes dieser gespeicherten Prozeduren im detail gegeben, die T-SQL-Quelle. Was ich nicht sagen kann, Sie ist, wie kann ich halten eine Reihe von gespeicherten Prozeduren, die die gleichen Maße, die ich entwickeln kann und zu verstehen, eine C# - code-Basis.
- Das ist schade, dann aus zwei Gründen. War mein Punkt, der etwas neues zu lernen, die Sie sagen, Sie nicht brauchen. Beiden war Ihre Behauptung, dass C# ist äquivalent zu SQL. Cheers und hoffe, dass Sie einen guten Tag haben.
- C# ist NICHT gleich SQL. Ich sagte so viel in der post. Aber als Teil der Transformation von Daten-Schicht, wo gespeicherte Prozeduren und ein C# - Programm mit Daten der Leser werden verwendet, um eine Daten-Schicht, wo, sagen wir, Entity Framework und LINQ-Abfragen werden verwendet, benötigen Sie zum übersetzen der T-SQL-code in die gespeicherten Prozeduren für die C# - code, der nicht die gleiche Sache. In Bezug auf die 70% der gespeicherten Prozeduren, die nur einfache Wählt bei Filter,, ist es nicht erkennbar-code, aber der code in der Form von LINQ-Abfragen. Und im Bezug auf die anderen 30% ist es definitiv-code.
- Fand diese, da ich überlege mir die gleiche Bewegung. Ich möchte einfach in der Lage sein, um source-control-meine Daten-Zugriff-code zusammen mit den Anwendungen und wollen nicht Busincess Logik in meine DAL.
- Diese Unterstützung setzen eine Tonne von business Logik in gespeicherten Prozeduren nicht machen keinen Sinn für mich. Diejenigen, die sagen, dass Sie jemals gut geschrieben mehrschichtigen Anwendungen mit real-Separationen Bedenken? Oder arbeiten Sie in isolierten Umgebungen, wo man nur das schreiben von Prozeduren, ohne andere sorgen in der Welt!?!?!
Du musst angemeldet sein, um einen Kommentar abzugeben.
Check-out Linqer: