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.

Naja, Du pustest Dir die Exe nicht so groß, lagerst statt dessen Code in DLLs aus. Fürs noch konsequenterem Strukturieren des Codes spricht vermutlich Variante 2. Für meine Zwecke reicht Variante 1.

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.

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

Hallo Leute

Ich mische mich hier mal ein
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.

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

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.