Kleine Frage zur Organisation von WPF-Projekten

  • WPF

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

    Kleine Frage zur Organisation von WPF-Projekten

    Neu

    Hallo,

    ich werde jetzt mein neues Projekt starten.
    Ich habe in der Organisation von Projekten jetzt mehrere Möglichkeiten gesehen.

    Einerseits legt man in seinem Projekt Ordner an ("ViewModel", "Model", "View").


    Andererseits macht man für diese Punkte einzelne Projekte


    Ich habe bis jetzt immer Variante 1 benutzt, in "professionellen" Projekten sehe ich allerdings immer Variante 2.
    Welche Variante ist jetzt besser? (gerne auch mit Erklärung)

    Vielen Dank für eure Hilfe.

    Viele Grüße
    Florian

    Neu

    IMHO: Das erste Bild organisiert ja Dein Projekt nur anders, nämlich in Ordnern. Das ist für Deine Übersicht. Aber es bleibt ein Projekt. Das zweite Bild spaltet das Ganze ja in mehrere Projekte auf. Dadurch kann man bestimmt einiges an Klassenentkopplung lernen. Aber ob es Sinn ergibt, sagen Dir bestimmt bald die Entwicklerprofis hier. Würde mich nicht wundern, wenn das einem Design Pattern entspricht, um die unabhängige Entwicklung von Projekten zu fördern, wenn mehrere Leute daran arbeiten. Aber als Alleinentwickler erkenne ich da momentan keinen Vorteil. Aber ich bin ja auch "nur" aus der WinForms-Ecke und handhabe das entsprechend Bild 1.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Neu

    Ich habe mir in der Zeit auch noch überlegt, dass ein Grund sein kann, dass wenn ich Änderungen an einem ViewModel vornehme, nicht gleich das ganze Programm neu kompiliert werden muss sondern nur die DLL des entsprechenden Projektes.
    Die einzelnen Projekte erstelle ich dann als Klassenbibiliothek, oder?

    Neu

    Ja, ok. Klar. Dass das Einzelkompilieren weniger zeitaufwenig ist, könnte ein Argument sein. Aber bedenke: "Premature optimization is the root of all evil" (D. Knuth). D.h. solange das Kompilieren jetzt nicht ewig und 3 Tage in Anspruch nimmt (oder zumindest störend relevant ist, da sollte man wirklich Vergleiche machen zwischen einem Projekt und 4 einzelnen!), ist das kein Argument. Es sei denn, dass Du das Projekt verteilst und nicht immer ne komplett neue EXE rüberschippen willst, sondern ggf. nur ne einzelne DLL. Ist natürlich auch ne Dateigrößenfrage (für die die gleiche Regel gilt: Erst testen und dann bewerten!).

    flori2212 schrieb:

    Die einzelnen Projekte erstelle ich dann als Klassenbibiliothek
    Dann hast Du 4 DLLs und wohl kein Programm, dass diese aufruft, oder hab ich was verpasst? Das ist schon ein in sich geschlossenes Projekt, oder? Weil dann braucht es natürlich irgendein Projekt, welches die DLLs auch nutzt. Alleine bringen sie Dir nicht viel.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Neu

    VaporiZed schrieb:

    Dann hast Du 4 DLLs und wohl kein Programm, dass diese aufruft, oder hab ich was verpasst? Das ist schon ein in sich geschlossenes Projekt, oder? Weil dann braucht es natürlich irgendein Projekt, welches die DLLs auch nutzt. Alleine bringen sie Dir nicht viel.


    Dann hab ich mich ein wenig falsch ausgedrückt, ich würde ein Projekt mit dem Namen "App" machen, als ganz normales Projekt was dann die drei DLLs (von "ViewModel", "Model", "View") nutzt.
    Ich hoffe das ist richtig, dass kann mir ja eventuell Nofear23M oder jemand anderes, der sich mit WPF auskennt sagen.

    Aber erstmal danke für eure Hilfe bis hierher.

    Neu

    Hi,
    ich mache eigentlich beides.
    Projektmappenordner anlegen für Application, Helper, Data, Model, Viewmodel und View und in diesen Ordnern dann einzelne Projekte anlegen.
    Der Vorteil von Projektmappenordnern ist, das du dann gleichzeitig deine Struktur auf der Platte geordnet hast und in der Quellcodeverwaltung.
    Die Projektmappenordner werden allerdings nicht auch automatich im Explorer angelegt, dies muss man händisch tun. Wie gesagt, ich sehe darin den Vorteil der Ordnung in der Quellcodeverwaltung und auf Platte
    "Hier könnte Ihre Werbung stehen..."

    Neu

    Hallo Leute

    Ich mische mich hier mal ein :P
    Auch wenn ich heute bereits ein paar Bier intus habe versuch ichs mal. Hui!
    Ich habe in den letzten Jahren sehr viel was solche Dinge betrifft probiert und muss ehrlich sagen das es echt darauf ankommt ob man Beispielweise MVVM, MVC oder anderen Pattern folgt oder ob man in einem Team arbeitet und/oder ob man gewisse Teile eines Programms an anderen Stellen oder in anderen Projekten benötigt.

    Dabei gehe ich aber immer davon aus das man wenn man alles in einem Projekt hat, alles "brav" in Namespaces unterteilt hat. Klar oder?

    flori2212 schrieb:

    Ich habe bis jetzt immer Variante 1 benutzt, in "professionellen" Projekten sehe ich allerdings immer Variante 2.

    Das liegt schlicht und ergreifend daran das man in "professionellen" Projekten aber auch oft UnitTests sieht, dazu aber gleich mehr.

    VaporiZed schrieb:

    Würde mich nicht wundern, wenn das einem Design Pattern entspricht

    Korrekt, MVVM "verlangt" die strinkte trennung zwischen den eizelnen Layern. Das kann zwar innerhalb eines Projekts genauso passieren, hat aber dann keinen Mehrwert und ich kann MVVM auch gleich lassen oder nur Teile davon umsetzen. Ein vorteil der Trennung in einzelne Projekte ist: Ich kann nicht "unabsichtlich" die View in ein ViewModel hereinholen.
    Lasst mich das näher erleutern. Wenn ich ein Projekte habe (WPF PRojekt mit der exe) dann habe ich in diesem Projekt alle Verweise (WindowsPresentationFoundation, XAML, WindowsBase usw.) und wenn cih im ViewModel nun ein Property von Typ Visibility anlege klappt dies auch und ich denke mir nicht viel dabei. Ist ja ein normaler Datentyp. Alles klar. NE!!! Ist es nicht. Visibility ist im Namespace System.Windows der PresentationCore.dll.

    Das ist der knackpunkt, Ich hole mir in diesem Moment die View ins ViewModel ohne es groß mitzubekommen. Warum? Ich muss keine Verweise hinzufügen. Die Imports werden mir einfach von VS vorgeschlagen und mit STRG + . ist es auch schon geschehen. Schon habe ich das Pattern verletzt! Scheint in diesem Moment aber auch nicht so tragisch zu sein, ich komme später dazu.

    Fakt ist, habe ich alles in einzelne Projekte unterteil fällt es mir sofort auf das ich einen Verweis hereinholen würde, ich müsste plötzlich ein paar Verweise setzen. (WindowsPresentationFoundation, XAML, WindowsBase usw.)

    VaporiZed schrieb:

    Aber als Alleinentwickler erkenne ich da momentan keinen Vorteil.

    Auch richtig. Zumindest im ersten Moment, aber denken wir weiter. OK, In WinForms gibt es weder Binding noch die möglichkeit ein richtiges MVVM zu implementieren.
    Aber was wenn wir weiterdenken. MVVM impliziert das wir die Layer trennen, aber haben wir uns bereits die Gedanken gemacht zu hinterfragen warum? Die wenigsten.
    Zum einen damit mehrere Entwickler daran Arbeiten können, richtig. Aber auch damit sowohl das komplette Model, als auch das ViewModel und evtl. noch andere Layer wie z.b eine Businesslogik oder ein Repository mittels UnitTests VOLL getestet werden kann. Ziel von MVVM ist es unter anderem das alles testbar wird. Das ist ein Vorteil den ich heute nicht mehr missen möchte. Klar, anfangs denkt man sich echt - warum tu ich mir das an das ich alles teste, ich weis ja das es funzt. aber glaubt mir. Ich habe schon PRojekte erstellt wo mehrere tausend Unittests drinnen waren. Und es ist echt von unschätzbarem Wert wenn ich mit einem klick innerhalb von ein paar Sekunden tausende Tests durchlaufen lassen kann und innerhalb von Sekunden weis ob mein Programm funktioniert oder ob ich gerade etwas "zerstöhrt" habe. Super genial.

    flori2212 schrieb:

    Ich habe mir in der Zeit auch noch überlegt, dass ein Grund sein kann, dass wenn ich Änderungen an einem ViewModel vornehme, nicht gleich das ganze Programm neu kompiliert werden muss

    Teilweise korrekt.
    Änderst du etwas am Model dauert das kompilieren sogar länger. Warum? Weil alle Projete neu kompiliert werden. Das ViewModel hat einen Verweis auf das Model. Muss also neu kompiliert werden, die View hat einen Verweis auf das ViewModel, wird also auch neu kompiliert das das ViewModel ja aufgrund der änderung des Model kompiliert wird. Wenn da jetzt wie angesprochen nochj weitere Layer dazwischen sind gehts natürlich weiter.
    Aber ja, änderst du etwas am ViewModel wird nur dieses und die View neu kompiliert.

    So, kommen wir nun noch abschliessend zur verletzung den MVVM Patterns. Es klingt im ersten Moment nicht schlimm das Pattern zu "verletzen", hole ich hald mal ein Control oder ein Fenster herein. Main Gott, da ich nicht vorhabe das ViewModel in einem anderen PRojekt zu verwenden ist dies nicht schlimm. Jein. Unter Umständen wird das ganze Projekt hierdurch untestbar!! Und das schreibe ich deshalb mit Rufezeichen da dies wirklich ein Punkt ist den ich jedem and Herz lege der vor hat ein größeres Projekt auf die Beine zu stellen.

    Erst vor kurzem habe ich einem Freund geholfen einen Fehler der wirlich etwas kniffliger war zu beheben. Da gab es wirklich sehr viele Abhängigkeiten und nur wenn gewisse Bedingungen erfüllt waren trat der Fehler auf. Aber auch nur dann wenn wiederum andere Bedingungen erfüllt waren. Ich kann euch sagen..... er hatte sein Projekt nicht für UnitTests konzipiert und ich bin fast ausgerastet beim Debuggen.
    Habe ich UnitTests schreibe ich schnell für jede Bedingung einen Test und lass diese mit einem Klick laufen. Ändere was an dem Code und lass es wieder laufen , usw.

    Dazu kommt noch das man kleinere updates raushauen kann. ändere ich nur die Optik meines Programms muss ich nur die dll für die View als Update raushauen und nicht immer und immer wieder ne große exe. Ich tausche nur die Dateien/Teile die sich geändert haben.

    Am ende ist es zu einem gewissen Teil Geschmacksache. Ich finde aber das es nicht großartig stört wenn ich alles in einzelne Projekte unterteile, auch wenn ich es vieleicht nicht benötige ist es nicht wirklcih mehr Arbeit, aber vieleicht ziehe ich später einen nutzen daraus. 8-)

    Verdammt, ich bin schon wie ein Lehrer. schreibe hier einen Roman nur über das Thema ob man die Projoktmappen aufteilen soll. Mann oh mann.
    OK, jetzt erstmal einen Kaffee, die Biere kommen echt gut.

    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. ##

    Neu

    Das war jetzt wirklich eine sehr Ausführliche Antwort.

    Ich werde die Aufteilung in Projekten benutzen, da sie ja kaum mehr Arbeit macht und irgendwann ja mal nützlich sein kann.
    Auch wenn ich gerade noch nicht weiß was UnitTests sind (klingen sehr interessant), die werden ja in deinem Tutorial behandelt.

    Vielen Dank nochmal für die Zeit die du dir immer nimmst, genieße deinen Kaffee :) :) :)

    Viele Grüße
    Florian

    Neu

    flori2212 schrieb:

    Auch wenn ich gerade noch nicht weiß was UnitTests sind (klingen sehr interessant)

    Es gibt ein sehr gutes Video. Auch wenn man es nciht glauben mag, dieses Video hat MICH zu UnitTests gebracht.
    OK, das Video geht noch weiter. TestDriveDevelopment bedeutet das man den Test schreibt bevor man die Methode schreibt. Also das man über den Test beschreibt was die Methode mach/kann/können soll.

    Der Test schlägt fehl. Klar, die Methode ist ja leer. Dann Code schreiben bis der Test erfolgreich ist -> Refaktoring -> evtl. einen Fehler eingebaut -> usw.
    Ich kann das Video nur empfehlen. Einfach damit man weis wo man mit MVVM hin kann(!!) wenn man will. Das heißt nicht das man sofort muss. aber es ist gut das man weis man kann und evtl. wenn nötig das man weis WIE man könnte.

    Und danke für die Lohrbeeren, tut gut. Gebe der Community aber gerne was, ich weis wie schwer ich selbst mir getan habe. Alles (zumindest was WPF und MVVM angeht) muss man sich mühsehlig zusammensuchen.
    Grüße
    Sascha

    EDIT: Ups, vergessen den Link zum video zu hinterlassen. :/




    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. ##

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