Gute Datenspeicherung?

Nabend Forum,

ich habe mal eine Frage:

Ich habe in meinem Programm Apotheken hinterlegt, die ich jetzt über eine "PharmacyManager" Klasse verfügbar machen will. In dieser Klasse sind Methoden zum Manipulieren der Daten vorhanden (anlegen, löschen, editieren etc... das Ganze Programm halt).

Der Methode zum Hinzufügen muss ich ja dann neue Daten übergeben und die Methode zum Erhalt von Daten gibt mir ja einen Satz von Daten zurück. Diese Datendetails wollte ich in einem struct ablegen, da mir das, meiner Meinung nach zumindest, die Vorteile von Überprüfungen etc. bietet (ist der Zip-Code 5-stellig etc.).

Folgendermaßen sieht mein struct zurzeit aus:

    public struct Pharmacy {
        private uint   id;
        private string token;
        private string name;
        private string city;
        private uint   zip;
        private string street;
        private uint   houseNumber;
        private uint   telephone;
        private string email;

        public uint ID {
            get { return this.id;  }
            set { this.id = value; }
        }

        [...]

        public Pharmacy(string name, string place) {
           [...]
        }
    }

Der Übersicht halber habe ich nur einen Teil gepostet.

Meine Frage ist jetzt: Ist diese Form der Haltung/Speicherung sinnvoll? Oder sollte ich das anders machen?

Der Methode zum Anlegen würde ich zum Beispiel ein struct übergeben. Ich kann mir dann schon sicher sein, dass die Daten, vom Format her zumindest, richtig sind.

Wie würdet ihr sowas lösen?

Gruß,
Fabian

Mein Verständnis vom .NET-Framework und der Philosophie sieht so aus:

• Du solltest die Daten mit ADO.NET speichern. Z.B. in einer DB oder einer XML-Datei.
• Über DataSets kannst Du dann transparent und unabhängig von der zugrundeliegenden physikalischen Speicherung zugreifen
• Nimmst Du noch typed Datasets hast Du auch die starke Typisierung.

Alternativ könntest Du Dir überlegen die Daten via Serialisierung in ein Speichermedium zu speichern/zu lesen.

Ich schließe mich Uwe an. DataSets bzw. DataTables sind bei verwendung von relationalen Datenbanken zu empfehlen. Bei XML-Datenquellen am besten XmlDocument benutzen.

Ich nicht,

so wie ich es verstanden habe, geht es in erster Linie noch gar nicht ums Speichern in einer Datenbank oder einer Datei. Es geht um die Datenhaltung im Speicher damit man damit arbeiten kann.

Und da würde ich die Daten nicht in einem XmlDokument halten, nur weil sie aus einer Xml-Datei geladen wurden oder in einem DataSet, weil sie aus einer Datenbank kommen. In einer OO-Anwendung werden die Daten normalerweise in einem Objektmodell (Klassendesign des abzubildenen Teils der realen Welt) gehalten.

Ich würde es genauso lassen wie es ist. Pharmacy ist eine Klasse/Struct des Objektmodells, sie definiert die benötigten Daten und die anwendbaren Operationen. Eine zweite Klasse ist der PharmacyManager, der für das Anlegen, Laden, Speichern, Löschen usw. von Pharmacy-Objekten zuständig ist. Wie und was nun genau gespeichert wird, bleibt seine Sache. Die Anwendung sieht nur Pharmacy-Objekte.

Gruss
Pulpapex

Hallo zusammen.

ich schließe mich Pulpapex an. Objekte sind bei Verwendung von objektorientierter Programmierung zu empfehlen. Bei objektorientierter Programmierung am besten Objekte benutzen. 🙂

herbivore

Hallo,

Auch ich schließ mich Pulpapex und herbivore an. Allerdings würde ich keine struct sondern eine Klasse verwenden. Der Unterschied ist klar der:
PharmacyManager["irgendwas"].Email = "a@b.c";
würde nicht wie erwartet die Emailadresse der Apotheke irgendwas ändern, da durch Unboxing ein komplett neuer Speicher reserviert wird und dort die Adresse geändert wird. In der Collection bleibt aber die alte Version aktuell.

Telefonnummern würde ich auch eher als strings speichern (oder sind nur 4 stellige-Apparatnummern gemeint?) In jedem Fall wäre eine -004 nicht speicherbar.

Außerdem wäre mal die Anzahl an Apotheken interessant. (Ich hab da ja keine Vorstellung von) Während bis 1000 noch alles im grünen Beraich sein sollte, wäre bei größeren Zahlen die Überlegung einer Indexstruktur zu machen und dann nicht alle Objekte zu erstellen. Nicht wegen Speicherverbrauch, allein damit das Laden von Dingen die man nie benutzt nicht unnötig Zeit kostet.

cu, tb

Hallo,

danke für die zahlreichen Antworten. Leider hatte ich mich nicht klar genug ausgedrückt. Es ging mir nicht primär um das Laden und Speichern in eine Datenbank oder XML-Datei, sondern, wie Pulpapex richtig bemerkt hat, um das halten der Daten zur Laufzeit im Speicher.

Ich werde es jetzt nicht mit einem Struct sondern mit einer eigenen Klasse machen, so dass ich die verschiedenen Apotheken in verschiedenen Objekten halten und jederzeit auf die Eigenschaften zugreifen kann.

Eine weitere Frage ist mir jetzt aber noch aufgekommen:

Bis jetzt hatte ich es so vor, dass ich zum Beispiel bei einem "Get" die Pharmacy-Objekte als ArrayList aus der Klasse PharmacyManger nach außen geben, um außerhalb mit denen weiterarbeiten zu können. Sollte ich das so machen oder gibt es einen besseren / sinnvolleren Weg, der mir bis jetzt nicht eingefallen ist?

Mir stellt sich zum Beispiel die Frage, wie ich die Daten am besten in eine ListView kriege. Eine bestimmte Anzahl mit der "Get"-Methode holen, die ArrayList benutzen und dann durch eine Schleife in die ListView packen?

Die Anzahl der Apotheken und damit die Anzahl der Objekte ist hier zu vernachlässigen, da es sich zurzeit um ca. 45 Apotheken handelt und das auch nicht mehr werden.

Gruß,
Fabian

In meinem Projekten lasse ich die Objekte immer sich selber anlegen/speichern/löschen. Dann habe ich alles in einem.

Auch verzichte ich meistens (aber nicht immer) auf einen übergeordneten Manager der Listen von Objekten zurückgibt. Stattdessen lasse ich das Objekt selbst via statischen Methoden Listen zurückgeben.

Z.B.:

public class Pharmacy
{
    public static Pharmacy[] GetAllPharmacies()
    {
        ....
    }

    public static Pharmacy[] SearchForPharmacies(
        string keyWord )
    {
        ....
    }

    ....
}