Modular programmieren

  • WPF

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von asusdk.

    Modular programmieren

    Hallo da draußen,

    hat jemand schon mal mit modularer Programmierung zu tun gehabt?

    Was ich meine:
    Verschiedene Anwender benutzen mein Programm, doch jeder ein wenig anders. Was dem einen besonders wichtig ist, spielt für den anderen keine Rolle.
    Und bei Updates an einem bestimmten Modul produziere ich vielleicht bei einem anderen Anwender Probleme, obwohl der diese Funktion gar nicht benutzt.

    Ich könnte meine Anwendung natürlich aufbauen wie z.B. PortableApps. Also jedes Modul ist eine vollständig eigene Anwendung, die ich lediglich über ein gemeinsames "Startmenü" zusammenfasse.
    Leider geht bei diesem Ansatz einiges an interner Kommunikation und intuitiver Benutzerführung verloren.

    Beispiel: Datenbank mit Adressen (klar, was sonst)
    Modul1 - wäre ein Veranstaltungsplaner mit Terminen, Preisen, Funktionen und Kommunikation
    Modul2 - soll Spendenprojekte unterstützen und Informationen, Spendenquittungen und Dankes- oder "Bettelbriefe" verwalten.
    Modul3 - jemand hat eine Telefonanlage und will aus dem Programm heraus telefonieren
    u.s.w. u.s.f.

    (Beispiel: Firefox kann durch AddOns erweitert werden.)

    Ich habe von der beabsichtigten Anwendung so gut wie nichts entwickelt (außer dass sie seit vielen Jahren als Access-Anwendung existiert).
    Ich habe nur den Verdacht, wenn ich gleich zu Beginn an solche Programmmodule denke, dann muss ich später nicht meine ganze Anwendung über den Haufen werfen.

    Also habt herzlichen Dank für eure Anregungen und euer Mitdenken!

    Programmier eins nach dem anderen ins Programm rein. Kapsel die Programmbereiche voneinander an so das man diese Unabhängig voneinander nutzen kann. Diese Bereiche sollten dann optional hinzugeschaltet werden können.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    Hallo

    Dein vorhaben ist ja im Grunde mittels MVVM leicht realisierbar ohne das du dich beim programmieren groß "verbiegen" müsstest.

    Du kannst damit leicht Module in Form von dlls machen. Ganz einfach verschiedenen ViewModels und dann wenn man will verschiedene Views in kleinere Pakete in Assemblys packen.
    Und will mans auf die Spitze treiben dann würde ich eine Plugin-Basierte Anwendung erstellen. Was unter WPF im Grunde auch nicht so tragisch ist.

    Aber die Antwort ist wohl auch eher allgemein gehalten, wir wissen ja nicht um was es genau geht, das würde ich mir von Fall zu Fall genau überlegen.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hallo,
    zum Thema

    Ich habe jetzt einen Artikel gefunden docplayer.org/34448323-Schritt…pf-and-silverlight-2.html
    Hier wird mit dem PRISM-Framework bzw. “Composite Application Guidance for WPF” Framework gearbeitet.
    Module (DLLs) werden dynamisch geladen und in spezielle "PRISM:Regionen" können Funktionen dieser Module in ein WPF-Fenster eingeblendet werden.
    Ob ich diese Regionen einfach frei lassen kann, wenn das entsprechende Modul nicht vorhanden ist, das muss ich mir erst noch anschauen.

    Das ist jetzt bestimmt nicht das "allein seligmachende" Framework und auch nicht die einzige Möglichkeit Modular zu entwickeln, doch irgendwo muss man ja mal anfangen.
    Nur so als Beispiel, "Wie haben andere so ein Problem angegangen?".

    Liebe Grüße

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

    Johannes schrieb:

    Nur so als Beispiel, "Wie haben andere so ein Problem angegangen?"

    Das kann doch pauschal garnicht beantwortet werden. Das kommt immer darauf an was benötigt wird.

    Als erstes muss geklärt werden ob die "Modularität" nur das Programmieren (Das Team) betrefen soll oder das Enduser auch. Also ob "Module" nachträglich vom User hinzugefügt werden sollen.

    Zum einen redest du davon das du für die Programierung den Code in Module "aufteilen" willst um später wie du sagst nicht alles "über den Haufen werfen muss" und zum anderen nennst du als Beispiel Firefox mit seinen AddOns.
    Das ist wie Äpfel mit Birnen zu vergleichen.

    Um ersteres zu realisieren ohne letzteres zu benötigen bedarf es weit weniger Aufwand als wenn letzteres benötigt wird.

    Das ist etwas was DU für dich erstmal entscheiden musst. WIE du es dann umsetzt hängt von deiner Entscheidung ab, ab diesem Zeitpunkt kann dich die Community hier dann auch unterstützen. Aber bei der Entscheidung eher weniger, zumindest nicht wenn wir nicht genau wissen WAS GENAU du hier Entwickelst.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Nofear23m schrieb:


    Das ist wie Äpfel mit Birnen zu vergleichen.


    Sorry,
    das ist zurzeit nicht konkreter zu benennen. Ich bin im Moment wie einer, der über den Gebrauchtwagenmarkt läuft und noch nicht weiß ob es ein 3 Türer, ein Hundefänger oder am Ende gar die Bahncard und der gelegentliche Mietwagen werden soll.

    Was ich bisher hatte, war eine Adressdatenbank.
    Bei einigen ist ein Veranstaltungsplaner dran,
    In einem Fall eine Spendendatenbank
    Und heute hatte ich die Nachfrage nach einer Rechnungsverwaltung.

    Also ich mache das in meiner Freizeit und beanspruche hier kein super Profiprogramm zu generieren, doch meine Freunde sind damit jahrelang gut klargekommen.

    In Access kann ich da relativ schnell ein paar Tabellen erstellen und mit referentieller Integrität, Zugriffsberechtigung und Einschränkungen ein "Modell" entwerfen.
    Der Rest ist Oberfläche.

    Warum dann nicht weiter in Access?
    Nun wäre da nicht Microsoft! Die haben sich in den letzten Jahren die "Inkompatibilität" auf die Fahne geschrieben. Und ich habe von Update zu Update Angst, welches Problem sich dieses Mal auftun könnte.

    ======================
    Die Module könnten also tatsächlich erst beim Anwender zusammen kommen. Evtl. könnte ein Modul von einem anderen Programmierer entwickelt werden (wenn der Kunde dafür einen Programmierer findet). Oder ich mache es wirklich wie PortableApps mit völlig eigenständigen Anwendungen.

    Ich wollte nur mal wissen, was es so für Blumen auf der grünen Wiese gibt. Also was für Konzepte zur modularen Programmierung überhaupt so "im Angebot" sind.

    Meine Module sind bisher "Sub-Datenbanken" und eigenständige Front-End-Datenbanken. Aber besonders wartungsfreundlich war das noch nicht.

    Und wenn ich das Rad sowieso neu erfinde, warum dann nicht mal über den Tellerrand hinausschauen

    Liebe Grüße
    Johannes

    *Fehlerhaftes Kommetar korrigiert* ~NoFear23m

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Nofear23m“ ()

    Naja, bisher hattest du es ja in Access eben nicht Modular. Du hattest im Grunde ALLE Programmiert und auch ALLES kompiliert wenn du irgendwo was geändert hast.

    Du hast nun die zwei oben genannten Möglichkeiten.
    Möglichkeit 1 ist in etwa das was du in Access bisher hattest mit dem Unterschied das du mit der Modularen programmierung einen sehr großen Schritt in richtung wartbarkeit deines Codes machst.

    Mit der Möglichkeit 2 (Pluginsystem) ist die Entwicklung der einzelnen Module weit komplexer (und wenn du mit WPF gerade Anfängst doch eher sehr Tricky) aber JEDER der Deine App hat kann wie du schon richtig sagst jederzeit Plugins dafür entwickeln (Was du trotzdem blockieren könntest so das nur DU dafür Plugins entwickeln kannst).

    DU musst entscheiden. Sonst niemand. Die Frage ist ob du so weit gehen willst, ich habe schon Pluginsysteme unter WPF entwickelt und kann dir sagen, da muss alle sitzen.
    Interfaces, Vererbung, Generische Klassen und das alles muss aus dem FF gehen.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Ich würde mich da nicht so verzetteln. Vor allem, wenn man Anfänger ist sollte man sich da nicht in so komplexes Zeug verrennen.

    Programmier ein Programm, welches per Freischaltung die entsprechenden Bereiche zur Auswahl anbietet. Eine Datenbank für alle Bereiche. fertig.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    Ich meine mich dunkel zu erinnern, das @Nofear23m mir einmal vermitteln wollte, wie man ein Programm am besten von Grund auf erdenkt, zuerst, sollte ich eine Art Skizze des Programmes erstellen, welches ich am Ende auch wirklich haben wollte, ein ungefähres Design, in Stichpunkten aufgeschrieben was das Programm können soll. Um deine Gedanken, dein Projekt betreffend einmal sauber zu sortieren, so kannst du letztlich auch erkennen, wie du dein Programm am liebsten aufbauen würdest, und kannst vorab entscheiden welche Art der Programmierung für dich hier am sinnvollsten erscheint. Versuche dir erstmal ein genaues Konzept vorzustellen, liste uns dann auf was dir durch den Kopf ging, dann kann dir sicher einer von den guten Leuten hier, einen Vorschlag machen, der dir dabei weiterhilft, aber wenn das Konzept noch so Vage aufgestellt ist, wird es sehr schwierig deine Frage direkt zu beantworten
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If