In welche Klasse packt ihr eure SQL-Funktionen im Projekt?

  • VB.NET

Es gibt 20 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    In welche Klasse packt ihr eure SQL-Funktionen im Projekt?

    Hallo Leute,

    ich habe bisher in meinen .NET Projekten mit nativen SQL-Abfragen gearbeitet und diese immer in eine Klasse "geschmissen".
    Also hatte ich immer eine große Klasse mit teilweise 100ten von Funktionen, auf die ich mit SQL_Con.<Funktionsname> zugreifen konnte. Da ich jetzt auf LINQ to SQL bzw. Entity Framework umsteigen möchte, habe ich mich gefragt, wo ihr diese Funktionen lasst?
    Habt ihr sie alle in einer großen Klasse, die für die SQL-Kommunikation zuständig ist, oder packt ihr diese in die Klassen eurer Objekte?

    Über ein paar Denkanstöße würde ich mich sehr freuen :)

    Genau so ein ähnliches problem habe ich derzeit auch.

    Da ich in meinem Projekt mit DataSet's arbeiten und auch schon min. 50 Funktionen habe welche LINQ to DataSet sind, habe ich mir auch überlegt diese der übersichthalber auszulagern.

    Allerdings ist der Zugriff auf ein DataSet immer nur aus einer Klasse möglich, bringt mir derzeit ein wenig ins wanken :(

    Hier zum Beispiel eine einfache Funktion zur Überprüfung der DB auf vorhanden Datensatz

    VB.NET-Quellcode

    1. Private Function tippExist(ByVal Heimmannschaft As String, ByVal Auswaertsmannschaft As String, Optional ByVal Spieldatum As DateTime = Nothing) As Boolean
    2. Dim Home As String = Heimmannschaft
    3. Dim Away As String = Auswaertsmannschaft
    4. Dim Datum As DateTime = Spieldatum
    6. Dim dsTipps = EshaBT.tblTipps.AsEnumerable.AsParallel
    8. Dim tippID = From t In dsTipps
    9. Where t.fldTHome = Home And t.fldTAway = Away
    10. Select t.fldTID
    12. Dim soloID = tippID.FirstOrDefault
    14. Select Case soloID
    15. Case Is >= 1
    16. Return True
    17. Case Is < 1
    18. Return False
    19. End Select
    21. Return Nothing
    22. End Function

    Naja ich habe halt eine Klasse mit dem Namen "SQL_Connection" erstellt und dort alle Funktionen reingepackt, mit denen ich mir Daten aus der SQL-Datenbank hole.
    Bloß ich habe halt bemerkt, dass es mit Zunahme der Funktionen immer unübersichtlicher wurde, wenn man alles in eine Klasse packt.
    Deswegen wollte ich wissen, in welche Klassen man am besten die Funktionen lässt, mit denen man Zugriffe auf die Datenbank ausführt, sei es Update / Insert oder Select.

    Eine typische Funktion wäre für mich halt:

    VB.NET-Quellcode

    1. ​ Public Shared Sub Add_Auftrag(ByVal Auftragsnummer As String, ByVal Kundenummer As String, ByVal BenutzerId As Integer, ByVal Lieferdatum As Date, ByVal Versandbeleg_Spezialfall As Integer, ByVal Versandart As Integer, ByVal Expressversand As Integer, ByVal LagerArt As String)
    2. Try
    3. conn.Open()
    4. Dim myCommand = New SqlCommand( _
    5. "Insert into Auftrag(Auftragsnummer,Kundennummer,Bestelldatum,BenutzerId, Lieferdatum, Spezialfall, Versandart, Expressversand, Lagerart) " & _
    6. "VALUES(@auftrag,@kundennr, @datum, @benutzer, @lieferdatum, @spezialfall, @versandart, @expressversand, @lagerart)")
    8. myCommand.Connection = conn
    9. With myCommand.Parameters
    10. .AddWithValue("auftrag", Auftragsnummer)
    11. .AddWithValue("kundennr", Kundenummer)
    12. .AddWithValue("datum", DateTime.Now)
    13. .AddWithValue("benutzer", BenutzerId)
    14. .AddWithValue("lieferdatum", Lieferdatum)
    15. .AddWithValue("spezialfall", Versandbeleg_Spezialfall)
    16. .AddWithValue("versandart", Versandart)
    17. .AddWithValue("expressversand", Expressversand)
    18. .AddWithValue("lagerart", LagerArt)
    19. End With
    20. myCommand.ExecuteNonQuery()
    21. ' Log your error
    22. Catch ex As Exception
    23. MsgBox(ex.Message())
    24. End Try
    26. conn.Close()
    27. End Sub


    Aber davon will ich ja weg mit Hilfe von LINQ

    @shaebich
    Das ist ja viel zu umständlich.

    VB.NET-Quellcode

    1. Private Function tippExist(ByVal Heimmannschaft As String, ByVal Auswaertsmannschaft As String, Optional ByVal Spieldatum As DateTime = Nothing) As Boolean
    2. Dim Datum As DateTime = Spieldatum 'was ist damit? Du nutzt es gar nicht
    4. Dim tipps = From t In EshaBT.tblTipps Where t.fldTHome = Heimmannschaft AndAlso t.fldTAway = Auswaertsmannschaft
    6. Return tipps.Count>0
    7. End Function

    @zvenner
    Hast Du Dich schon einmal mit dem Thema "Typisierte Datsets" auseindergesetzt?
    Damit ist Programmierung wie in Deinem Beipiel schlicht überflüssig. Der FormDesigner macht das alles für Dich, es werden 1000ende Zeilen Code erstellt, die typsicher und bombproofed sind.

    @WhitePage

    ich weiß, ist auch gedacht wenn die Datenbank mal mehrere Jahre inne hat, da es sicherlich in der Bundesliga jedes Jahr ein paar gleich Partien gibt.
    Die Funktion war auch nicht final, deswegen erstmal ausfühlich und verständlich.

    Ich finde eh, viele Programmierer verkürzen ihre Funktionen so dermaßen. Dann muss man sich erst wieder 3h eindenken bevor man wieder weiß, was die funktion eig. machen soll.


    WhitePage schrieb:

    Nein, deine war unnötig in die Länge gezogen. Die Prüfung auf ID ist vollkommen überflüssig, zumal die IDs eigentlich negativ sein sollten.


    Was war daran unnötig? Bitte kläre mich auf.
    Erstmal, die Prüfung auf ID ist genau dann notwenig wenn ich wissen möchte ob die ID > 0 ist, da 0 meine Dummy ID ist.

    Wieso sollten diese ins Negative laufen? Ich weiß, beim typisierten dataset laufen die Auto spalten "eig." ins Negative. Allerdings ist dies meiner Meinung nach egal in welche Richtung meine ID's zählen.

    Ich dachte, du wolltest prüfen, ob ein Datensatz mit diesen Parametern (Heim- und Auswärtsmannschaft) existiert. Dafür reicht eine Abfrage, ob solch ein Datensatz gefunden wurde.
    Was soll dieses AsEnumerable.AsParallel?

    Eine feste Prüfung auf ID-Wert ist sehr fehleranfällig, wenn du die IDs aus irgendeinem Grund doch negativ machst.

    Was ist jetzt mit der Dummy-ID? Woher kommt sie? Erstellst du für alle Möglichkeiten einen Datensatz mit DummyID=0? Das kann nicht sein, sonst würden sie sich wiederholen.

    Also ich weiß jetzt nicht ob ich wirklich alles so richtig verstanden habe was hier gefragt wird.
    Ich hatte mir ebenfalls immer SQL-Klassen "gebaut", da waren aber keine Vorgefertigten Abfragen drin sondern Functions, an die ich notwendige Paramter übergeben konnte. Bei einem früheren Versuch mit LINQ, war es zwar kompliziert aber machbar.
    Mittlerweile habe ich mich, durch die Arbeit mit PHP in die Richtung MVC bewegt.
    Wobei es ein Model gibt, das die Daten der DB hält. Somit sind einzelne Abfragen fast unnötig.
    Grüße Manu

    Was Gott dem Menschen erspart hat, kann der Computer.
    Billy ©, (*1932), Schweizer Aphoristiker
    Quelle: www.Aphorismen.de

    WhitePage schrieb:

    Was ist jetzt mit der Dummy-ID? Woher kommt sie? Erstellst du für alle Möglichkeiten einen Datensatz mit DummyID=0? Das kann nicht sein, sonst würden sie sich wiederholen.


    Ist jetzt in dieser Abfrage nicht ersichtlich, aber in den anderen Tabellen habe ich das Prinzip eines Dummy Kreditoren aus SAP übernommen. In anderen Tabellen gibt es z.B. wie in Tabelle "Liga" 170 Ligen der Welt. ID = 0 ist meine Dummy Liga, sollte ein Verein nicht eindeutig einer Liga zugeordnet werden können (wir automatisch über einen WebClient und diverse Seiten aktualisiert und gepflegt), wird dieser Eintrag vorerst der Dummy Liga zugeordnet. Dort kann ich dann über eine weitere Abfrage ganz einfach alle "Mannschaften" mit Dummy = 0 anzeigen lassen und manuell der richtigen ID zuordnen.

    WhitePage schrieb:

    Eine feste Prüfung auf ID-Wert ist sehr fehleranfällig, wenn du die IDs aus irgendeinem Grund doch negativ machst.


    Aus welchem Grund soll ich dies tun?

    WhitePage schrieb:

    Nein, ich meine, wozu brauchst du es, wenn es auch ohne geht? Und was ist mit meinen anderen Fragen?


    Wieso nicht? Ich habe dadurch keinen Nachteil, außer die 11 Zeichen...

    D.h. du prüfst nicht, ob der Datensatz mit diesen beiden Mannschaften existiert, sondern ob dieser Datensatz eine FremdID gleich 0 hat oder nicht? Was ist denn, wenn dieser Datensatz gar nicht existiert (Ich dachte, bei TippExists würdest du danach prüfen)? Irgendwie ist es gerade komplett unlogisch.

    shaebich schrieb:

    Aus welchem Grund soll ich dies tun?


    Die Frage ist nicht, ob du es tun sollst. Sondern dass du hardcodiert reinprogrammierst, dass du es nie tun wirst... Wieso fragst du nicht einfach, ob sie 0 ist?

    shaebich schrieb:

    Ich habe dadurch keinen Nachteil, außer die 11 Zeichen...


    Das ist eine sehr seltsame Logik, die du hast. Sollen wir jetzt alle unnötige Funktionen aufrufen, nur weil es nicht stört? Deswegen meinte ich ja,

    WhitePage schrieb:

    unnötig in die Länge gezogen



Facebook
Telefonspende