Ein Mitglied meines Teams ist vor kurzem zu LinqPad als sein primäres Abfragetool gewechselt (wird immer noch gelegentlich mit SQL Studio arbeiten), um sich selbst dazu zu zwingen, die Verwendung von LINQ natürlicher zu machen. Ich dachte, das wäre eine ziemlich gute Idee und erwäge, den Rest meines Teams um einen Wechsel zu bitten. Hat jemand irgendwelche Gedanken / Ideen zu diesem Ansatz?
Früheste Fragen, die ich hatte ...
Ich glaube, dass ich in der Lage bin, gutes ANSI SQL zu schreiben, ist für einen LOB-Entwickler von entscheidender Bedeutung. Da LINQ eine Microsoft-Sache ist, sind die Fähigkeiten, die sie in LINQ lernen, das Opfer bei der vollständigen Entwicklung ihrer ANSI-SQL-Techniken wert, insbesondere wenn sie später im Leben zu anderen Aufgaben / Aufgaben übergehen. Entwicklerentwicklung (innerhalb und außerhalb der Firma) ist mir sehr wichtig.
Gibt es irgendwelche Funktionen in SQL Studio, die in LinqPad schmerzlich vermisst werden?
Hat LinqPad eine lange Lebensdauer? Mit anderen Worten: Hat jeder das Gefühl, dass LinqPad ein Produkt ist, das weiter wachsen wird, wenn .NET und SQL wachsen?
Um LINQ in sich selbst zu bohren, ist LINQPad großartig, und wenn Sie als Entwickler planen, innerhalb der Microsoft-Ökologie zu bleiben, dann ist das wahrscheinlich eine gute Sache.
Ja, es gibt eine Reihe von Dingen, die Sie in LINQ nicht tun können, für die Sie möglicherweise ein anderes Tool benötigen, ob das nun SQL Management Studio oder Visual Studio ist, aber Sie können in der Sprache auf SQL zurückgreifen gemildert, wenn Sie sich das SQL dafür merken können:
Offensichtlich sind dies meist "Management" -Aktivitäten.
Während LINQPad Ihnen den Ausführungsplan nicht gibt, gibt es Ihnen die SQL, die ausgeführt wird.