eigenes kleines Warenwirtschaftssystem schreiben - Vorüberlegungen

  • VB.NET

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von VB1963.

    eigenes kleines Warenwirtschaftssystem schreiben - Vorüberlegungen

    Hallo Leute

    Da es mir in meiner VBA (Excel) Programmierung unheimlich geeholfen hat, Programme zu schreiben, die ich dann auch tatsächlich nutze und dadurch aktiv weiterentwickeln kann, habe ich vor dies auch in VB.Net zu tun.
    Ich möchte mir also ein kleines Warenwirtschaftssystem programmieren, welches (erstmal) folgende Funktionen haben soll:
    1. Anzeigen der Artikel im Programm (in meinem gekauften WWS befinden sich ca. 15.000 Artikel
    2. ein verändern eines (mehrerer) ausgewählter Artikel - mithilfe eines Fensters / dieses soll grundlegene Infos darstellen (Artikelname, Nr, Ean Code, Kalkulaton, usw)
    3. Updatefunktion über Dropbox, oder OneDrive (brauche ich nicht wirklich - habe ich aber in einem Youtube Tutorial gesehen - finde ich einfach cool) allerdings kann ich auf diese Weise meine Geschwister einfacher ins Beta Testing bringen :o)
    Dazu treffe ich gerade ein paar Grundüberlegungen. Durch meine schlechten VB.Net Kentnisse tue ich mich da aber recht schwer.

    Meine Fragen:
    1. In welchem Format empfiehlt es sich eine solche (langsam wachsende) Datenmenge zu speichern?
    Reicht hier eine csv, oder ist dies einfach nicht performant genug, wenn ich diese in eine DatagridView importiere?
    Oder bekomme ich in einer csv auch Probleme, wenn ich einzelne (oder mehrere) Zeilen mittendrin ändere?
    Wäre dann aus einem der beiden, oder einem anderen Grund, die Anbindung an eine Datenbank sinnvoller?
    2. Sollte ich die Datagridview (oder eine andere Control) zum zeigen der Artikel in die Hauptform einbetten, oder lieber eine Childform erstellen, oder vielleicht in einer Tab control, welche diese anzeigt?
    Denn wenn z.B. in späteren Versionen ein Rechnungswesen hinzukommt, muss ich mir ja Gedanken machen, dass ich die Artikelverwaltung in irgendeiner Form ausblenden muss, um Platz zu schaffen, für die Rechnungsverwaltung. Oder mache ich mir hierüber erst Gedanken, wenn es soweit ist, weil sich ja dadurch der Code nicht, oder nur wenig ändert?
    Das würde ich über ein typisiertes Dataset machen und die Daten kannst du einfach in ein .XML-File speichern bzw. davon laden. Das Dataset stellt dir dazu 2 Methoden zur verfügung. Bei 15000 Artikel ist das kein Poblem. Du kannst das Ganze später auch ohne Weiteres via Datenbank abwickeln.
    Wie es sich momentan anhört, möchtest du vorerst nur eine Tabelle berabeiten. Dazu bräuchten wir aber mehr Informationen...
    Man kann das Datenmodell später schrittweise erweitern und ausbauen...
    Schaue dich im Tutorialbereich Datenbanken um - da hat EDR eine Menge davon verfasst...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VB1963“ ()

    VB1963 hat das wchtigste schon gesagt. tDS ist erstmal das Zauberwort. Es hat anfänglich einen Nachteil: Mehrbenutzerfähigkeit erstmal ausgeschlossen. Da ließe sich später - wie ebenfalls durch meinen Vorschreiber erwähnt - durch ein DBMS später verbessern/erreichen. Aber bis Du soweit bist, hast Du schon ganz andere Hürden genommen. Also erstmal tatsächlich tDS-only.
    In deiner 2. Frage wägst Du zwei nicht miteinander vergleichbare Optionen ab: DGV oder ChildForm. Nicht vergleichbar, weil ein (Child)Form selber keine Daten darstellen kann. D.h. Du brauchst auf dem ChildForm selber passende CEs. Aber ob Du jetzt ein DGV nimmst oder eine Sammlung von anderen CEs wie Labels+TextBoxes+CheckBoxes usw., bleibt Dir überlassen. Was Du für sinnvoll erachtest. Wird auch alles bei EdRs VVV beschrieben, wie man beides mithilfe des Datenquellenfensters durch Drag&Drop in Sekundenschnelle erreichen kann.
    Das TabControl ist zwar ne gute Layout-Option. Aber ggf. wäre es sinnvoller für neue Programmteile wie das Rechnungswesen ein eigenes Programm zu schreiben. Denn sie bauen zwar alle auf den gleichen Artikeldaten auf. Aber inhaltlich haben sie nicht oft was miteinander zu tun. Was käme ggf. zusammen: Artikelinfo, Wareneingang, Bestellwesen, Kassenbuch, Rechnungswesen, ...
    Je mehr Du in ein Programm reinhaust, desto unübersichtlicher wird es. Aber um es klar zu machen: unterschiedliche Programme funktionieren nicht tDS-only. Zumindest nicht gleichzeitig. Wenn Du die Artikelinfo schließt und dann den Wareneingang öffnest, dann ist es wiederum tDS-only möglich. Schließlich brauchst Du ja immer die aktuellen Daten. Und wenn 2 User oder 2 Programme gleichzeitig an den Daten rumbasteln ... Chaos.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    @DerSmurf Wofür willst Du so ein Ding basteln?
    Für Dich selbst, als größere Übung?
    Für Deinen Chef, um zu fetzen?
    Anhand Deiner Fragestellung sehe ich, dass Du (noch lange) nicht reif bist, eine solche Problemstellung anzugehen.
    Wen Du trotzdem damit anfängst, wirst Du Dich in einem Jahr in einem Wust von Spagetticode wiederfinden, den Du selbst nicht mehr lesen magst.
    Und uns fragst Du dann ständig, wie Du Deine selbstgemachten Fehler beheben kannst.
    Lass es lieber sein.
    Sorry.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Neben dem Punkt von @RodFromGermany würde ich bei neuen Projekten einen ORM wie Entity Framework oder nHibernate nutzen.
    Du planst ja auch keinen neuen Tesla der dann mit einem Super-Verbleit-Benziner angetrieben wird.

    Kleiner Nachtrag: Updatern sind hier ganze Threads gewidmet.
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.
    @RodFromGermany
    Danke für deine ehrlichen Worte.
    Ich sehe das Programm als große Übung für mich. (einen Chef zu Beeindrucken würde bei mir auch nicht funktionieren / und Prahlerei liegt mir eh fern)
    In meiner VBA Zeit hat es mir sehr geholfen, Programme zu schreiben, die ich dann auch regelmäßig verwendet habe.
    Hier hatte ich dann deutlich mehr Spaß daran diese weiter zu entwicklen, da ich quasi mein eigener Beta Tester bin und wenn ich im laufenden Betrieb merke, da fehlt was, oder das und das wäre so angenehmer - hab ichs halt gemacht.

    Ich bin allerdings davon ausgegangen, dass dieses Projekt nicht so schwer sein wird.
    Denn in VBA hat das (auch zu meiner Anfangszeit) keine großen Probleme dargestellt (allerdings hatte ich hier keine Datenbank, sonder habe die Daten direkt ins Exelsheet gespeichert), was ja scheinbar ein größerer Unterschied ist, als ich dachte :(

    Aber wenn du der Meinung bist, das ist noch nichts für mich, denke ich nochma drüber nach und verschiebe das auf später
    Denn funktionierenden (aber schlechten) Code in was gescheites umzuwandeln, hat mich in VBA zu viel Zeit gekostet und zählt echt nicht zu den DIngen die dann Spaß machen.
    Also erstelle ich mir jetzt einen Tea Timer und danach einen Taschenrechner mit ein paar Zusatzfunktionen und schaue weiter Youtube Tutorials.

    Edit zur Eingangsfrage:
    Das eine Childform an sich keine Daten darstellen kann ist mir schon bewusst.
    In meiner Frage Nummer 2 oben ging es grundlegend darum, wo ich die Daten aus der Datenbank anzeigen soll.
    Auf der Hautform selber, oder lieber eben in einem entsprechenden Control in einer ChildForm, um das "Hauptprogramm" aufgeräumter zu halten und nicht später "Platprobleme" zu bekommen.
    Hallo Leute
    Ich möchte das Thema typisiertes DataSet nocheinmal aufgreifen.
    Da ich dieses gerade Testweise in meinen TeaTimer einbaue (also kleines warmwerden quasi).
    Ich habe mich jetzt in den letzten Tagen intensiv mit den Threads und Youtube Filmchen von @ErfinderDesRades auseinandergesetzt.
    An dieser Stelle echt mal vielen Dank für die geilen Erklörungen und die ganze Mühe die du dir damit gemacht hast!

    Aber ein paar Fragen habe ich dennoch:
    1. In allen Tuts vom EdR werden neue Daten immer direkt in eine Datagridview geschrieben.
    Wie sieht es aus, wenn ich das erstellen eines neuen Eintrages mittels Code in einem gesperrten Datagridview erledigen möchte.
    An vielen Stellen wird in den Tutorials erwähnt, dass man die benötigten Daten nicht aus dem Gridview, sondern aus der Table ziehen soll.
    Aber wie verhält es sich mit neuen Einträgen?
    Schreibe ich diese per Code ins Gridview - weils ja eh ein Binding mit der Table hat, oder ist es auch hier eleganter, die Daten direkt in die Table zu schreiben? Wenn ja, wie?

    2. auch alle Änderungen, werden immer über gebindete Elemente veranlasst.
    Wie verhält es sich, wenn ich das ganze mit einem button "speichern" machen möchte?
    Also sagen wir ein primitives Adressbuch:
    Name / Vorname / Nummer
    wird angezeigt in einer Detailview.
    Wenn ich nun im Gridview einen Namen anklicke, werden meiner drei Textboxen gefüllt.
    Wie kann ich nun dafür sorgen, dass nach Änderung in einer Textbox das ganze erst nach Klick auf Speichern (z.b. zum validieren der Daten) in die Table übernommen wird?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „DerSmurf“ ()

    Das wird auch in den Videos besprochen, vielleicht sogar gleich im ersten.
    Zur Erstellung einer "einfachen" Zeile ohne Abhängigkeiten zu anderen Tabellen: DerNameDeinerTdsInstanz.DerNameDerTabelleDieDuBefüllenWillst.Add...Row(DeineParameter)
    Als Beispiel:
    Deine tDS-Instanz auf Deinem MainForm heißt Tds. In Deinem tDS selbst hast Du eine DataTable namens Teas*, in dieser Tabelle gibt es die Spalten ID (Int32), Name (String), Temperature (Int32) und BrewingTimeInMinutes (Int32). Dann schreibst Du, um der Tabelle einen neuen Datensatz (= eine komplette Tabellenzeile) zu geben:

    VB.NET-Quellcode

    1. Tds.Teas.AddTeasRow("Darjeeling", 90, 3)
    -> neuer Tee mit Namen Darjeeling, Temperatur = 90 °C, Ziehzeit 3 Minuten.

    *für alle Plural-als-DataTable-Name-Gegner: ja, ich bin Anhänger der Pluralbenennung, da in der Tabelle mehrere (in diesem Fall) Teesorten gespeichert werden und ich mehr For Each Tea In Teas in meinem Code zu stehen habe als Tds.Teas.AddTeasRow() (und da wäre nämlich auch nur der AddTeasRow-Teil grammatikalisch falsch, von daher für mich das kleinste Übel)
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Arf, ja du hast vollkmmen recht.
    Direkt im ersten Video gitbt es einen Code, der die Table mit Daten füllt und auch eine erklärung dazu. Sorry, habe ich irgendwie verdrängt.
    Aber zum speichern mittels Button (und eben nicht automatisch) habe ich nix gefunden (hab die Videoreihe gerade noch einmal geschaut).
    Also letztendlich muss ich ja auch irgendwie gezielt Einträge in meiner Table auswählen und ändern können.
    Hast du da auch einen Tipp für mich?

    edit: vergiss es bitte, wenn ich alles gucken will, sollte ich auch wirklich alle Videos schauen und nicht das in dem meine Fragen erklärt werden, überspringen...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „DerSmurf“ ()

    DerSmurf schrieb:

    Aber zum speichern mittels Button (und eben nicht automatisch)
    Also die Settings werden automatisch beim Schließen der Anwendung vorgenommen, wenn du das so voreingestellt gelassen hast.
    Beim Dataset ist das nicht so - da musst du das Speichern selber in die Hand nehmen. Da bietet dir das Dataset eine Methode dazu an: .WriteXML - das findest du auch in den Tut's von EDR beschrieben.