DataTable Inhalt auf Festplatte speichern und lesen



  • Hallo.

    Ich habe mir eine Classe MyDataTable von System.Data.DataTable abgeleitet und um ein paar Funktionen erweitert. Nun möchte ich den Inhalt von MyDataTable auf die Festplattte schreiben und wieder lesen. Dazu habe ich folgenden Code geschrieben:

    public class MyDataTable : System.Data.DataTable
        {
            public MyDataTable() : base() { this.SharePointConnectData.Clear(); }
    
            #region Save and Load from Harddisk
            public string SaveDataToHardDisk(string FileName)
            {
                try
                {
                    FileName = FileName.Replace("\\", "/").Replace(@"\", "/");
                    if (System.IO.File.Exists(FileName)) { System.IO.File.Delete(FileName); }
                    System.IO.FileStream fs = new System.IO.FileStream(FileName, System.IO.FileMode.Create);
                    System.Runtime.Serialization.Formatters.Binary.BinaryFormatter bf = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
                    bf.Serialize(fs, this);
                    fs.Close();
                }catch (System.IO.IOException) { }
    
                return FileName;
            }
    
            public void LoadDataFromHardDisk(string FileName)
            {
                try
                {
                    FileName = FileName.Replace("\\", "/").Replace(@"\", "/");
                    System.IO.FileStream fs = new System.IO.FileStream(FileName, System.IO.FileMode.Open);
                    System.Runtime.Serialization.Formatters.Binary.BinaryFormatter bf = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
                    this = (MyDataTable)bf.Deserialize(fs); /*Fehler!!! - Cannot assign to this because it's read only*/
                    fs.Close();
                }
                catch (System.IO.IOException) { }
            }
            #endregion
    }
    

    Weiß jemand von Euch, wie man das abändern muss, dass es funktioniert?

    Grüße,
    CJens



  • s. z.B. Deserialize to self

    Designtechnisch ist das aber keine gute Idee dies mittels Vererbung lösen zu wollen (sofern du nicht wirklich eigene Eigenschaften hinzufügst) - besser wären dafür Extension-Methods (unabhängig von deinem Compilerproblem).

    PS: Dein FileName.Replace ist unnötig (und dann auch noch doppelt gemoppelt, denn

    "\\"
    

    entspricht

    @"\"
    

    ), denn .NET kann mit beiden Pfadtrennzeichen umgehen.
    Und einen leeren catch-Zweig solltest du auch vermeiden.
    Dir scheinen (wenn ich das so auch aus deinen anderen Beiträgen herauslese) noch einige (C#-)Grundlagen zu fehlen.



  • Was hast Du in diesem Fall gegen Vererbung? Die Klasse läuft in einem anderen Program, welches auf .NET basiert und die System.Data.DataTable nutzt. Bisher hat das mit der Vererbung immer wunderbar geklappt. Was stört Dich daran bzw. was ist der Vorteil der Extension-Methode?

    Ja, mühsam ernährt sich das Eichhörnchen und mir fehlen sicher noch einige Grundlagen... das weiß ich.
    Das mit dem Replace ist notwendig, da es auch eine Funktion gibt, welche Dateipfade an das Hauptprogram (ein RPA Roboter von BluePrism), der mit dem Delimiter "/" arbeitet, zurückgibt - dahier auch public string SaveDataToHardDisk().

    Ich habe "das Problem" jetzt über eine Statische Methode gelöst... die Integrität in der Klasse wäre mir lieber gewesen...



  • Was hast Du in diesem Fall gegen Vererbung?

    1. damit du speichern/laden kannst muss ein System.Data.DataTable ein MyDataTable sein
    2. es gibt nichts was der MyDataTable mehr kann als Speichern/Laden, auch keinen Zustand - warum also das ganze - damit es wohl schöner aussieht

    mit einer Extension-Methode auf dem System.Data.DataTable bekommst du das gleiche aussehen - und brauchst keine extra Klasse - die sowieso dafür da ist das du deine neuen Methoden irgendwo reinstecken kannst

    man versucht im allgemeinen so wenig wie möglich über Ableitung zu erreichen - steht der generischen Nutzbarkeit sehr häufig im Weg



  • Ist ja auch kein Verbrechen, wenn es schöner aussieht. Speichern kann ich MyDataTable auch sehr schön und laden (über eine externe, statische methode) auch.

    Eine Klasse abzuleiten benötigt auch nur wenige Zeilen... also sehe ich da auch nicht wirklich den Nachteil. Wenn unser Roboter eine DataTable zurück gibt, kann ich diese über einen Konstruktor auch sehr einfach in eine MyDataTable umwandeln... geht aber sicher mit Extension-Methods auch.
    Ich werde es mal so umsetzen wie ihr das sagt... auch wenn ihr mir (bis auf die generische Nutzbarkeit) nicht wirklich viele Gründe genannt habt.

    Ich bin ja gespannt, wann ich das erste Mal im Forum darauf hingewiese werden, dass System.Data.DataTable keine Funktion mit den Namen Load / SaveFromHardDisc() beinhaltet 😉



  • Ist ja auch kein Verbrechen, wenn es schöner aussieht.

    das ist kein Problem - dafür brauchst du aber keine extra Klasse - und wenn du mal 1,20 oder gar 100 solcher Szenarien hinter dir hast wirst du wissen warum ein paar Sinnlos-Klassen mit den paar Zeilen und dem bisschen Ableiten doch ganz schön bloed werden - und du dann auch noch diese Sinnfrei-Spezialklassen durch alle Schnittstellen verteilst - und nach ein paar 100k Zeilen Code und x anderen Entwicklern die mit drann arbeiten nicht mehr los wirst - oder den Samen der Sinnlos-Klasse in denen auch noch gesät hast 🙂

    Speichern kann ich MyDataTable auch sehr schön und laden (über eine externe, statische methode) auch.

    und das sollte erst mal reichen - erst wenn du Abstraktion ala verschiedenen Quellen Load/Saver brauchst lohnt sich wieder OOP - ohne das ist es auch kein OOP sondern nur Namespaces - also faktisch static classes

    kann ich diese über einen Konstruktor auch sehr einfach in eine MyDataTable umwandeln

    einfach und schnell ist selten der richtige Grund für ein Design - wartungsarm, erweiterbar, pflegeleicht, vielschichtig anwendbar eher - dein ist eine trivial-Funktion in eine Klasse gestopft - ohne Grund - State- und Scopeless so viel wie geht

    auch wenn ihr mir (bis auf die generische Nutzbarkeit) nicht wirklich viele Gründe genannt habt.

    dir fehlt einfach noch Erfahrung um die Auswirkung deines ist-doch-nett-so-Designs zu überblicken - in ein paar Jahren machst du das dann nicht mehr - hoffe ich

    Ich bin ja gespannt, wann ich das erste Mal im Forum darauf hingewiese werden, dass System.Data.DataTable keine Funktion mit den Namen Load / SaveFromHardDisc() beinhaltet 😉

    Ich würde ehrlich gesagt auch eher eine statische Methode aus einer Helper-Class machen (es gibt ja leider keine wirklich freien Funktionen in C#) - macht deinen Code nicht 1 Zeile länger oder kürzer und ich glaube nicht das du die Save/Load Routinen permanent in deinem Code an allen Ecken und Enden aufrufst



  • Da kann ich Gast3 voll zustimmen! 👍

    Und zu

    kann ich diese über einen Konstruktor auch sehr einfach in eine MyDataTable umwandeln

    :
    in C# kann man nicht ein Objekt in ein anderes Objekt (einer anderen Klasse) umwandeln (ohne ein neues Objekt zu erzeugen und eine komplette (Deep-)Copy zu machen).



  • Wenn unser Roboter eine DataTable zurück gibt

    dein "Roboter" sollte keinen DataTable zurückliefern - sowas macht nur eine Datenbank
    oder kennst du einen Roboter dessen "physische" Fähigkeit ist Datenbank-Results zu liefern? Was steht denn in dem DataTable von dem Roboter?

    Design bedeutet nahe Echtweltabbilddung, NICHT: alles leicht technisch nutzbar machen, dazu gehört z.B. auch das man nicht den Roboter einen DataTable liefern laesst damit man es leichter in ein GUI bekommt - ja - manchmal muss man der Ordnung wegen auch Umwege gehen

    man sollte niemals etwas irgendwo deswegen reinbauen weil es dann technisch einfacher(schöner) nutzbar ist - nach diesem Schema haben dann normalerweise alle Objekte irgendwelche Spezialfeatures (die ganz schön) sind und dann relativ schnell stören (wenn es mehr Zeilen Code werden und andere Leute daran arbeiten) - aber wie gesagt alles eine Erfahrungssache



  • Und Harddisk ist vielleicht ein technisch cooler Name - verliert aber jeglichen sinn wenns keine Harddisk sonder Ramdisk oder sonstwas ist - da kannst du deine Routinen auch saveonfat32harddisk nenenn, lieber saveto loadfrom file


Anmelden zum Antworten