Wohin mit den Sql Befehlen

Reverent

Erfahrenes Mitglied
Hallo Leute,

ich habe ein Porgramm geschrieben, welches Kunden und Kontaktdaten verwaltet.

Nur habe ich jetzt "überall" in meinen C# Code die SQL Befehle, wenn sich jetzt eine Tabelle ändern sollte muss ich in meinem Code alle betreffenden Statements anpassen.

Wir löst Ihr das Problem?

Bis Dann
Reverent
 
Tabellen ändern sich ja nicht einfach so. D.h. da ist dann meist auch eine Änderung an der Business Logik, als auch an der View notwendig.

Für deine SQL-Statements würde es sich anbieten, einen eigenen Bereich zu definieren, an dem sie abgelegt sind. Da gibt es natürlich unterschiedliche Ansätze. Auch die Verwendung eines O/R-Mappers wäre denkbar, wobei du hier (je nach verwendetem Framework) das Mapping anpassen musst.

Änderungen bleiben dir auf keinen Fall erspart.

PS: Grundsätzlich sollte man sich darüber bereits vorher Gedanken machen.
 
Also ich würde die SQL Statements zB in statischen Konstanten in einer eigenen Klasse dafür oder in einer XML Datei halten. Dann hast du wenigstens eine zentrale Stelle, an der du ändern musst, und musst nicht im ganzen Programm suchen.

Darüber hinaus empfielt es sich, so viel Logik wie möglich in die Datenbank selbst auszulagern. Also arbeite so weit wie möglich mit Stored Procedures usw.
 
Hallo Ihr,
danke für euere Antworten.

Ich werde mir die ganze Sache noch mal genauer überlegen müssen.

Was ist denn wann genau vorzuziehen?
Und zwar direkt mit DataTables arbeiten oder die Daten nach dem die DataTables gefüllt sind
auf in diverse Objekte zu kopieren. z.B.

dataAp.Fill(dtKunde);
List<Kunde> lstKunde = new List<Kunde>();
FillListKunden(ref lstKunde, dtKunde);
...
textBox.Text = lstKunde[0].Name;

Bis Dann
Reverent
 
Hallo Reverent,

an deiner Stelle würde ich die SQL's erstmal in eine .resx-Datei schreiben. Hier hast du den Vorteil das du sie an einem zentralen Ort abgelegt und dir die Möglichkeit offen gehalten hast sie im nachhinein anzupassen.

Bei deiner zweiten Frage, was vorzuziehen ist, kommt es erstmal stark drauf an was du genau machen willst. Ein eigenes Objekt um die einzelnen DataRow's zu basteln ist natülich einfacher zu handeln wenn du Daten an den Objekten ändern und mit den .net-Bordmitteln wieder in die Datenbank schreiben willst. Dabei solltest du dann aber beachten, dass sich die Poperties deiner Objekte im Hintergrund an den Zellen der DataRow aufhängen.

Code:
private DataRow _MyRow;
internal DataRow MyRow { get { return _MyRow;} set { _MyRow = value; }}

public string Name { get{ return this.MyRow["Name"].ToString(); } set { this.MyRow["Name"] = value; } }
 
Hallo M4st3r,
erstmal ein Danke für deine Antwort.

Aber was genau meinst du damit:
Dabei solltest du dann aber beachten, dass sich die Poperties deiner Objekte im Hintergrund an den Zellen der DataRow aufhängen.
Ja, und du hast recht am Ende läuft es hier darauf hinaus:
Code:
public string Name { get{ return this.MyRow["Name"].ToString(); } set { this.MyRow["Name"] = value; } }

Bis Dann
Reverent
 
Ich meine genau das, was du im 2. Codefenster stehen hast. Ich wollte nur vorbeugen, nicht dass du auf die Idee kommst die DataRow per Constructor zu übergeben und in dem Object dann anhand der Zellen string/int/etc.-Variablen füllst die du dann nach außen verfügbar machst.

Du hast im übrigen, solltest du mit DataTable und -Row arbeiten, noch zusätzliche, nützliche Features die du nutzen kannst. Du kannst beispielsweise abfragen, ob sich ein Objekt verändert hat - Stichwort: "Rowstate"
 
Hallo M4st3r,

warum sollte man die nicht machen?
Ich wollte nur vorbeugen, nicht dass du auf die Idee kommst die DataRow per Constructor zu übergeben und in dem Object dann anhand der Zellen string/int/etc.-Variablen füllst die du dann nach außen verfügbar machst.
 
Hallo Leute,

hat den keiner eine Antwort warum man dies nicht machen sollte!
Ich wollte nur vorbeugen, nicht dass du auf die Idee kommst die DataRow per Constructor zu übergeben und in dem Object dann anhand der Zellen string/int/etc.-Variablen füllst die du dann nach außen verfügbar machst.

Bis Dann
Reverent
 

Neue Beiträge

Zurück