Habe ich das so richtig verstanden? (WPF MVVM Bootstrapper IoC)

Hallo zusammen,

ich hab im moment noch leichte verständnis probleme bei meiner Architektur.

Ich liste erstmal auf, welche Assembly ich habe und welchen zweck die erfüllen sollen:

1. Main.exe ( Hat die App.cs )
2. View.dll ( dort sind nur die Views drinne und gegen Interfaces programmiert)
3. ViewModel ( auch gegen Interfaces programmiert )
4. Model ( da sind die ganzen Datenklassen drinne (Interface))
5. Repository ( Kapselt die zugriffe auf den WCF / EF4 / XML je nach Anwendung (Interface))
6. Contracts ( hat alle Interfaces )
7. Bootstrapper ( hat den IoC )
8. MVVM Framework (Caliburn wird es denke ich werden) ( wird in Bootstrapper und ViewModel referenziert )
9. LightCore ( wird in allen Assemblys referenziert )

Die Assemblys sollen sich ja gegenseitig nicht kennen.
Der Bootstrapper muss aber um den Container bauen zu können alle Assembly kennen, bis auf die App.exe . Die Assemblys müssen dann aber den Bootstrapper kennen, um damit abhängigkeiten auflösen zu können. Die Main.exe kennt nur den Bootstrapper und lässt sich die erste View auflösen und bekommt ein UIElement vom Bootstrapper zurück und fügt das dem RootVisual hinzu.

Ich hab mir das mal schematisch aufgezeichnet und mit pfeilen markiert, wie die Assembly sich gegenseitig kennen. Dabei kennt keine Assembly die sich schon aufrufende.

Sollte ich bis dahin schon auf dem falschen weg sein, korrigiert mich bitte.

Das würde mich bei meiner Entwicklung schon einen entscheidenden schritt weiter bringen, wenn ich wüsste, das dies so auf keine weiteren probleme stoßen wird, die eventuell erst wesentlich später bemerkt werden und dann die änderung recht umfangreich und zeitraubend wären.

Ich hab die letzten tage viel mit lesen verbracht. Das beinhaltet alles, was ich im Titel stehen habe, um da eine Basis bauen zu können, die solide genug sein sollte, damit eine umfangreichere Anwendung schreiben zu können.

Nun suche ich einfach ein bisschen rat, um das Chaos in meinem Kopf zu richten. Denn es ist für mich im moment noch ein kleines problem, zu wissen, ob mein ansatz der richtige ist, wenn man keine erfahrung mit solchen projekten besitzt.

Danke schon mal.

Grüße Stephan

Hallo,

...ich hab im moment noch leichte verständnis probleme bei meiner Architektur... Wer soll deine Architektur verstehen, wenn nicht du selber? 😉 Aber ich weiß was du meinst.

Es sind ein paar Punkte bei die ich nicht ganz nachvollziehen kann, bzw. die ich eventuell anders lösen würde.

2. View.dll ( dort sind nur die Views drinne und gegen Interfaces programmiert) Was brauch die Views für Interfaces? Das sind doch einfache XAML Dateien wo du nur die Bindings an Properties und Commands angibst. Mehr ist doch da nicht nötig.

Die Assemblys müssen dann aber den Bootstrapper kennen, um damit Abhängigkeiten auflösen zu können. Naja, nicht wirklich. Ich kenn LightCore nicht, aber normalerweise würdest du ja nur ne externe XML Config haben um die Dependencies zu konfigurieren, aber keinesfalls sollte der Bootstrapper die anderes Assemblies als Referenz haben. Ansonsten ist da nicht viel getrennt. Weil wenn der Bootstrapper alle Assemblies referenziert und die einzelnen Assemblies den Bootsstrapper um Abhängigkeiten auflösen zu können, dann hast du über den Bootsstrapper ja ne Abhängigkeit eines einzelnen Assemblies von allen anderen.

Die Main.exe kennt nur den Bootstrapper und lässt sich die erste View auflösen und bekommt ein UIElement vom Bootstrapper zurück und fügt das dem RootVisual hinzu.

Diese Trennung hätt ich nicht zwangsweise gemacht. Wenn die eigentliche App die Views kennt halte ich das für in Ordnung. Ich hätte halt die MainView sozusagen fest angegeben und mir dann per DI das dazu passende ViewModel geben lassen und der Rest ergibt sich ja dann sozusagen 😉 Ich mein prinzipiell ist die Trennnung wie du sie hast natürlich gut möglich und erlaubt dir praktisch den gleichen Applikationsrumpf mit verschiedensten Applikationen zu benutzen, aber mir persönlich ist das den Aufwand nicht wert.

Zum MVVM Framework:
Dies hat doch schon einen eingebauten Mechanismus zur Dependency Injection. Da würd ich mich nach dem richten und kein zusätzliches eigenes benutzen (so liest sich das momentan bei dir). Da du noch nicht festgelegt zu sein scheinst - schau dir mal Cinch an, ebenfalls auf Codeplex zu finden. Das verwendet in V1 auch klassisch DI, aber ist in V2 vollkommen davon abgekommen und verwendet MEF. Das hat einen großen Vorteil: Man gibt den entsprechenden Programmteilen nur entsprechende Attribute und MEF setzt das Programm praktisch selber zusammen. Da muss man sich nicht mehr groß drum kümmern die Abhängigkeiten zu konfigurieren.

Hallo Stipo,

für eine solche Architektur kann ich dir WAF empfehlen.

zero_x

Hallo zusammen,

@zero_x
Ich hab mir die tag einige Framworks angesehen. Sicher hat jedes irgendwo seine vorzüge, wie dann auch nachteile. Bei Caliburn bin ich am schnellsten durchgestiegen, wie man das verwendet. Rob Eisenberg hielt auf der Mix einen langen vortrag wie man ein minimalistisches Framework bauen kann Build Your Own MVVM Framework. Muss gestehen das hat mich beeindruckt, und ich konnte dem ganzen sehr gut folgen. Auch hab ich mir mal den Code den er bei dem vortrag verwendet hat angesehen. Das war sehr aufschlussreich um das tiefer vestehen zu können.

@talla

Zitat:
Die Assemblys müssen dann aber den Bootstrapper kennen, um damit Abhängigkeiten auflösen zu können.

Naja, nicht wirklich. Ich kenn LightCore nicht, aber normalerweise würdest du ja nur ne externe XML Config haben um die Dependencies zu konfigurieren, aber keinesfalls sollte der Bootstrapper die anderes Assemblies als Referenz haben. Ansonsten ist da nicht viel getrennt. Weil wenn der Bootstrapper alle Assemblies referenziert und die einzelnen Assemblies den Bootsstrapper um Abhängigkeiten auflösen zu können, dann hast du über den Bootsstrapper ja ne Abhängigkeit eines einzelnen Assemblies von allen anderen.

Okay, wenn ich das mit XML configuriere, brauche ich keine abhängigkeiten zu den Assemblys. Nur bleibt dann noch eine andere frage. Ich muss dann ja irgendwo eine Instanz des Container rein packen, die dann alle assembly erreichen können. Sonst kann ja ein Repository zB kein Model referenzieren, wenn es ein neues leeres Model zurück liefern muss.
Wo packe ich die Referenz dann hin?

Diese Trennung hätt ich nicht zwangsweise gemacht. Wenn die eigentliche App die Views kennt halte ich das für in Ordnung. Ich hätte halt die MainView sozusagen fest angegeben und mir dann per DI das dazu passende ViewModel geben lassen und der Rest ergibt sich ja dann sozusagen 😉 Ich mein prinzipiell ist die Trennnung wie du sie hast natürlich gut möglich und erlaubt dir praktisch den gleichen Applikationsrumpf mit verschiedensten Applikationen zu benutzen, aber mir persönlich ist das den Aufwand nicht wert.

Das heist, ich kann den Bootstrapper, die Views und die App.xaml in der Haupt Assembly belassen? So verstehe ich das jetzt zumindest mal.

Zum MVVM Framework:
Dies hat doch schon einen eingebauten Mechanismus zur Dependency Injection. Da würd ich mich nach dem richten und kein zusätzliches eigenes benutzen (so liest sich das momentan bei dir). Da du noch nicht festgelegt zu sein scheinst - schau dir mal Cinch an, ebenfalls auf Codeplex zu finden. Das verwendet in V1 auch klassisch DI, aber ist in V2 vollkommen davon abgekommen und verwendet MEF. Das hat einen großen Vorteil: Man gibt den entsprechenden Programmteilen nur entsprechende Attribute und MEF setzt das Programm praktisch selber zusammen. Da muss man sich nicht mehr groß drum kümmern die Abhängigkeiten zu konfigurieren.

Ich muss ja auch die Models und Repository indizieren lassen können. Daher hab ich LightCore im Auge. Das ist leicht und kann doch alles, was man braucht.

Cinch hab ich mir auch mal angesehen, bin aber nicht sofort durchgestiegen. Was natürlich auch am Englisch liegen kann, da es schwerer zu lesen ist.

Ich denke ich hab aber das hauptsächliche jetzt verstanden, und werde mal beginnen das so umzusetzen.

Danke nochmals.

Grüße Stephan

Wo packe ich die Referenz dann hin?

Einfach ne statische Klasse mit nem statischen Property welches du beim Start der Applikation initialisierst. Kannst ja jederzeit dann darauf zugreifen und die Assembly wo diese statische Klasse drin ist hat selber ja keine Abhängigkeiten, andere Assemblies können somit problemlos darauf referenzieren.

Ich muss ja auch die Models und Repository indizieren lassen können. Daher hab ich LightCore im Auge. Das ist leicht und kann doch alles, was man braucht. Ja, aber auch Caliburn hat doch schon alles eingebaut, selbst MEF wird unterstützt wie ich grad auf deren Seite gesehen hab. Zwei verschiedene DI Systeme zu benutzen kann kaum gut gehen. Was ist nämlich wenn du eine Abhängigkeit in beiden brauchst? Dann musst du nämlich zusehen das du wirklich genau das gleiche Objekt in beiden zur Verfügung stellen kannst.

Cinch hab ich mir auch mal angesehen, bin aber nicht sofort durchgestiegen. Was natürlich auch am Englisch liegen kann, da es schwerer zu lesen ist.[/qzote]
Wie gesagt, mein Favorit aber da können Geschmäcker verschieden sein. An Cinch ist halt wirklich gut das in mehreren Codeproject Artikeln alles bis ins kleinste Detail erklärt ist und das ganze System logisch erscheint. Das was ich von Caliburn bisher in deren Dokuseiten gesehen hat, hat mich echt nicht überzeugt.