pureMVC Verzeichnis-/package-Struktur bei mehreren MVCs

[charly23121977]

Wie sieht eine vernünftige Package-/Verzeichnisstruktur unter Verwendung von pureMVC aus, wenn ich für meine Anwendung (Flash/AS3) mehrere MVCs brauche.
Beispiel: Ich habe einen Preloader in meiner Anwendung der mehrere Dateien laden soll. Dieser soll mit pureMVC realisiert werden. Also lege ich nun ein Package wie folgt an: de.charly.myproject.loader. In diesem Package liegen weitere Packages für model, view und controller. Nun brauche ich noch parallel dazu ein weiteres MVC, dass mit dem ersten kommuniziert, und sich um den Hauptbereich der Anwendung kümmert. Das Package lautet z.B. de.charly.myproject.main. Ist es nun vernünftig, auch in diesem Package wieder jeweils ein Package für model, view und controller anzulegen? Oder leg ich diese Packages model, view & controller im de.charly.myproject-Package direct ab und lasse die Packages de.charly.myproject.loader und de.charly.myproject.main einfach weg? Gibt diesbezüglich vielleicht noch andere Ansätze?

[Marcy_LH]

Warum sollte man das für ein und das selbe Projekt trennen?

Muss nicht der Weisheit letzter Schluss sein, aber
meine PureMVC-Projekte lege ich wie folgt an:

tld.kundendomain.projektname.assets //enhält meine Viewklassen
tld.kundendomain.projektname.core //enhält Preloader, Mainklasse
tld.kundendomain.projektname.patterns.controller //enhält commands in verschiedenen subpackages
tld.kundendomain.projektname.patterns.facade //enhält nur die facade
tld.kundendomain.projektname.patterns.model //enthält alle proxies und VOs im package vo
tld.kundendomain.projektname.patterns.view // enthält alle Mediatoren

das ist nur ein grober Überblick.

[charly23121977]

Warum sollte man das für ein und das selbe Projekt trennen?

Das war nur ein Überlegungsansatz von mir. Habe mich erst vor kurzem mit pureMVC bekannt gemacht und wollte einfach nur mal in Erfahrung bringen wie das andere so angehen.

Deine Package-Struktur finde ich einen guten Ansatz. Hat mir erstmal sehr geholfen.

Danke schön!!!

[Omega Psi]

Wobei ich nach fachlichen Aspekten strukturieren würde, nicht nach Pattern...

[Marcy_LH]

das heißt genau? (mit Bitte um ein Beispiel)

[laxersaz]

Nach Patterns finde ich auch nicht sinnvoll.

Wir haben es beim aktuellen Projekt so gelöst:

de.firmenname.projektname.core.controller.commands
de.firmenname.projektname.core.controller.interfac es
de.firmenname.projektname.core.controller.model.no tifications
de.firmenname.projektname.core.controller.model.pr oxies
de.firmenname.projektname.core.controller.model.vo s
de.firmenname.projektname.core.controller.model.vi ew.components
de.firmenname.projektname.core.controller.model.vi ew.events
de.firmenname.projektname.core.controller.model.vi ew.mediators
de.firmenname.projektname.core.controller.model.vi ew.ui

Darunter liegen natürlich wieder Packages mit den konkreten Klassen

In de.firmenname.projektname.core liegt unsere AppFacade

Und dann gibts diese Grundstruktur inklusive diverser Zusatzpackages nochmal in de.firmenname.shared -> das ist unser Grundframework
de.firmenname

Insgesamt haben wir so bei unseren ca. 350 Klassen eine gute Struktur.

[Omega Psi]

Die Verzeichnisstruktur ist doch nach Patterns aufgebaut.

[rendner[i]]

Ich persönlich würde für jedes MVC-Projekt eine Struktur aufsetzen. So ist alles etwas übersichtlicher und man wird nicht von Klassen erschlagen die zu anderen Projekten gehören.
Vorteil daran ist auch das so der Code leichter woanders verlinkt werden kann und nicht erst alle Klassen die zu einem Projekt gehören extrahiert werden müßen.

[charly23121977]

Also die Lösungen von laxersaz und Marcy_LH sind ja doch recht ähnlich und im Ansatz auch ganz gut. Mich würde nun aber interessieren was Omega Psi genau damit meint, das ganze nicht nach Pattern sondern nach fachlichen Aspekten zu strukturieren. Ebenso bin ich ganz neugierig, wie die Lösung von redner[i] konkret aussehen würde.

Wurde eigentlich für diese hier diskurtierte Problematik nicht schon irgendwo irgendwelche Standarts bzw. Richtlinien festgelegt, also so ähnlich wie bei der Ordner-Struktur eines Software-Projekts, das unterteilt wird in Ordner wie bin, lib, src etc.

[malthoff]

Ja, in der Anleitung zu PureMVC wird empfohlen(vielleicht auch in den zig Beispielanwendungen, die man runterladen kann), es nach Pattern zu strukturieren, also einen Ordner für alle Models, einen für die Controller und einen für die Views. Das wäre nach Pattern unterteilt, weil das zugrundeliegende Pattern Model-View-Control heisst. Diese Struktur sollst Du innerhalb einer Anwendung natürlich nicht für jeden Teil duplizieren, sondern einfach alle Modelle, Views und Controller in die Ordner packen.

Wenn Du allerdings mit Multicore PureMVC anfängst, machst Du für jeden Core (abgeschlossener Teilbereich deiner Anwendung, eventuell ein Modul) eine neue Ordnerstruktur auf - wiederum mit einem Model, View und Controller Ordner.

OmegaPsi findet das nicht gut, weil es von der Semantik her wenig aussagekräftig ist, eine Problemdomäne nach generischen Worten wie Model, View und Control zu organisieren - schätze ich

[rendner[i]]

Struktur würde bei mir ungefähr so aussehen (ganz grob).

com.blabla.videoplayer

• model
• view
• controller

com.blabla.mp3player

• model
• view
• controller

Jedes Modul würde bei mir auch einen eigene Facade besitzen, so das sich diese auch wirklich leicht woanders verwenden lassen, ohne das ich irgendwelchen overhead von anderen Dingen mit "rumschleppe".

[Omega Psi]

Ja, so in der Richtung mache ich das auch. Ich versuche Patterns wie oder Abkürzungen wie "vo", "proxy" etc in packages zu vermeiden, da sie leider dann doch schon of in den Klassennamen vorkommen. Mich nerven diese Redundanzen und ich möchte, dass die Datentypen eine gutes und damit auch lesbares Modell abbilden. Ich unterteile in der Regel in model, view, controller und services.

[laxersaz]

Ah! Jetzt versteh ich, was du meinstest, Omega. Insofern halten sich unsere Packages an die Bestandteile der jeweiligen Patterns (model, view, controller, commands, etc.). Darunter sind aber Unterpackages für z.B. die konkreten Komponenten.

[charly23121977]

Danke euch allen für die guten Ansätze.