Stark typisierte gespeicherte Prozedurauflösung In VB.NET

Question

Gegenwärtig erzeugen wir Klassen in App_Code, indem wir alle Sprocs von allen unseren Datenbanken zurückgeben und die korrekten Parametertypen und Namen zu einem SqlCommand Objekt hinzufügen und es dann in einer riesigen Klasse zurückgeben. Das heißt, wir können Dinge wie MyCmd.cmd.Parameters("MyParam").Value = "whatever" tun, wenn wir Parameter an eine SqlCommand für eine gespeicherte Prozedur übergeben wollen, ohne die Parameter mit ihren relativen Datentypen jedes Mal hinzufügen müssen, wenn wir einen Anruf tätigen. Es bedeutet auch, dass wir die exponierten Parameter für jeden Sproc nachschlagen müssen, da sie nur Strings sind.

es in die richtige Perspektive zu setzen, für jeden Parameter, den Sie mit in einem sproc beschäftigen möchten Sie, dies zu tun haben würde:

cmd.Parameters.Add(New System.Data.SqlClient.SqlParameter("@Param", 3, 10, 1, False, CType(0, Byte), CType(0, Byte), "", System.Data.DataRowVersion.Current, Nothing)) 

Wirklich dies ist unerwünscht, da es ein Intranet/Internet-Anwendung bedeuten würde würde in Milliarden von Codezeilen explodieren, um wirklich recht einfache Aufgaben zu erfüllen.

Wir untersuchen das Refactoring so, dass wir etwas wie MyDatabase.MySproc.MyParam("value") machen können, indem wir es stark typisieren. Leider bedeutet dies, dass unser Ordner App_Code doppelt so groß ist, wie es bereits ist, weil eine so große Menge Code benötigt würde.

Ich habe ein kleines Beispiel von dem, was geschrieben ich meine:

Public Class MyProc 

    Dim cmd As SqlCommand 

    Public Sub New() 
     ' uses the ConfigurationManager to get the connection string for a certain DB' 
     Dim cmd As New SqlCommand("MyProc", GetSqlConnection()) 
    End Sub 

    Public Sub Param1(ByVal param As String) 
     cmd.Parameters.Add(New System.Data.SqlClient.SqlParameter("@Param1", 3, 10, 1, False, CType(0, Byte), CType(0, Byte), "", System.Data.DataRowVersion.Current, Nothing)) 
     cmd.Parameters("Param1").Value = param 
    End Sub 

    Public Sub Param2(ByVal param As String) 
     cmd.Parameters.Add(New System.Data.SqlClient.SqlParameter("@Param2", 22, 7000, 1, False, CType(0, Byte), CType(0, Byte), "", System.Data.DataRowVersion.Current, Nothing)) 
     cmd.Parameters("Param1").Value = param 
    End Sub 

    Public Sub Param3(ByVal param As String) 
     cmd.Parameters.Add(New System.Data.SqlClient.SqlParameter("@Param3", 3, 1, 1, False, CType(0, Byte), CType(0, Byte), "", System.Data.DataRowVersion.Current, Nothing)) 
     cmd.Parameters("Param3").Value = param 
    End Sub 

    Public Function GetReturnValue() As String 
     cmd.Parameters.Add(New System.Data.SqlClient.SqlParameter("@RETURN_VALUE", 8, 0, 6, False, CType(0, Byte), CType(0, Byte), "", System.Data.DataRowVersion.Current, Nothing)) 
     Return cmd.Parameters("RETURN_VALUE").Value 
    End Function 
    End Class 

Gibt es Alternativen zu haben, dies zu tun, dass wir nicht bewusst? Ich bin mir sicher, dass dies ein häufiges Problem bei vielen Unternehmen ist, die Inter-/Intranet-Anwendungen entwickeln.

Answer 1

Warum verwenden Sie nicht LINQ to SQL? Auch wenn Sie keine Query-Elemente verwenden möchten, können Methoden zum Aufrufen gespeicherter Prozeduren generiert werden.

Answer 2

Oder SubSonic, die eine sehr schöne SPs statische Klasse erzeugt, wobei jeder Sproc eine aufrufbare Funktion ist und (glaube ich) eine DataTable zurückgibt.