Objektorierentiert bei Datentransfer?

Hallo

Hab mal eine Grundlegende Frage an euch.
Macht es eigentlich Sinn, objektorientiert zu arbeiten, wenn man eigentlich nur Daten aus einem XML File in eine Datenbank rüberschaufeln will???
Bzw. was wäre die Vor- Nachteile von OOP ?
Danke für eure Antworten

Ben

Mit .NET arbeitest du immer objektorientiert, ob du willst oder nicht....

Meinst Du mit "objektorientiert" den Zugriff auf die Datenbank über einen OR-Mapper?

Falls ja, machst das nur für das übertragen von XML-Daten in eine Databank keinen Sinn. Ich würde eher ADO.NET verwenden (Verbindung zur DB herstellen, XML-Datei mit XmlTextReader lesen und per parametrisiertem Command die Daten als Datensätze in die entsprechenden Tabellen schreiben).

naja ich mein, dass ich meine Tabellen als Objekte sehe und dafür eine "spezielle" Klasse anlege welche dann noch meine zusätzlich benötigte Operationen beinhaltet(wie z.b. löschen einer Reihe in einer Tabelle )
Macht denn sowas überhaupt Sinn?
oder wie handelt Ihr eure DataSets?
Greift ihr einfach nur per Indizierung direkt darauf zu?
wie z.b. so DS.Tables[0].Rows[1].ItemArray[1] ?

Man holt keine ganzen Tabellen in ein DataTable-Objekt und greift über Index zu. Stell Dir vor Du hast mal zwei Millionen Datensätze in einer Tabelle. Es wäre quälend lahm und Dein Arbeitsspeicher wäre irgendwann komplett dicht.

Normalerweise trifft man eine Vorauswahl über Kriterien (z.B. "Alle offenen Aufträge von Kunde XY" statt "Alle Aufträge"). Das ganze formuliert man in einer SQL-SELECT-Anweisung. Sinnvoll sind statuslose Klassen, die den Datenzugriff auf bestimmte Geschäftsentitäten kapseln. Für eine Auftragsverwaltung könnte man z.B. eine OrderManager-Klasse schreiben. Ein Client kann die Funktionen dieser Klasse verwenden, um Daten abzurufen und zu speichern. So könnte das z.B. aussehen:

// Offene Aufträge von Kunde XY abrufen
DataTable openOrders=_orderManager.GetCustomersOpenOrders(customerID);

// Aufträge in einem DataGridView anzeigen
myDataGridView.DataSource=openOrders;

Du solltest das Zeilenweise (Cursor orientierte) Denken (z.B. löschen einer Reihe) aufgeben und lieber mengenorientiert denken. Löschen von Zeilen, züfügen von zeilen und Ändern von zeilen kann die DataTable bereits. Es ist aber meistens nicht sinnvoll bei jeder einzelnen Änderung UPDATEs, INSERTs und DELETEs auf der Datenbank auszuführen. Die DataTable "merkt" sich, wenn der Benutzer Zeilen bearbeitet, bzw. neue zugefügt oder gelöscht hat. Über den DataAdapter können alle Änderungen an den Zeilen auf einen Rutsch in der Datenbank gespeichert werden.

Klassen für die verwaltung einzelner Tabellen sind also gut, aber sie sollten statuslos und mengenorientiert sein.

Die Möglichkeiten von SQL sollte man auch in einer objektorientierten Welt nutzen.

Mit anderen Worten, es macht also wenig Sinn eine Abstrakte Klasse "MyDataTab" zu schreiben (welche alle benötigten von mir vorgesehenen Funktionen beinhaltet), wenn sich die einzelnen Tabellen von einander unterscheiden?

So ist es. Du solltest zwischen Datentransportcontainer (DataTable/DataSet) und Datenzugriffsfunktionalität immer trennen. Das gehört nicht in eine Klasse. Objektorientiertheit ist in dieser Forum bei Verwendung relationaler Datenbanken eher negativ zu sehen.

Selbst bei der Verwendung von OR-Mappern wird getrennt.

Also ich würde jetzt grob gesehen eine Klasse für den Datenbankzugriff, eine für den Datenaustausch (DS / SQL-DB) , und eine für die Manipulation des DataSets schreiben.
Oder wie wäre das ganze am sinnvollsten?

So in der Art könnte das aussehen: Tree(Node) Collection als Zwischenschicht bauen

Es ist natürlich nur ein Beispiel und bietet viel Potential für Verbesserungen. Die Grundlegende Vorgehensweise die ich meine sollte dadurch aber klar werden.

Dieses Beispiel hier zeigt auch, wie man das ganze verteilt (Funktionen einer Anwendung auf unterschiedliche Rechner aufteilen und dort laufen lassen) aufsetzt.
Tree(Node) Collection als Zwischenschicht bauen

super das schaut gut aus.....werd ich mir mal zu gemüte führen.
Vielen Dank 😁 👍