2009-03-02 9 views
2

Ich bin derzeit damit beschäftigt, alle Entwickler in der Firma, in der ich arbeite, über Silverlight (v2) zu unterrichten. Das einzige Problem ist, dass ich selbst keine echte Silverlight-Erfahrung habe. Natürlich habe ich alle technischen Details über Sachen wie Datenbindung, Layout usw. studiert, damit ich meinen Kollegen helfen kann. Aber eine Sache, über die man kaum Informationen findet, ist die allgemeine Projektstruktur.Empfohlen Prism v2 Silverlight/WPF Projektstruktur

Ich habe mich entschieden, dem P Prism 2-Pfad zu folgen (und womöglich sogar einige WPF später in den Mix zu werfen) und so habe ich mich gefragt, ob jemand von euch clevere Leute Erfahrung in der Entwicklung eines echten Projekts mit Prism hat 2 oder auch nur WPF, und wenn Sie Vorschläge zur Projekt-/Lösungsstruktur hatten? Wie "Wo stellst du Ansichten ein?" oder "Haben Sie Namenskonventionen für Modulprojekte?" usw.

Jede Hilfe wird sehr geschätzt.

Antwort

7

Dies basiert rein auf meiner Erfahrung mit Prism für WPF, nicht Silverlight. Ich bin kein Experte für Prism und könnte meine Meinung bei einigen davon leicht ändern. :-)

  • Es ist verlockend, ein Modul für alles zu machen. Nicht. Ihre Bauzeit wird schnell explodieren und Sie haben eine sehr gebrochene Lösung. Stattdessen habe ich ein Hauptmodul, das statisch geladen wird und alles enthält, was ich im Basispaket haben möchte. Alle Addons oder Extras werden zu anderen Modulen, die dynamisch geladen werden. Es könnte sich lohnen, das eine Modul etwas zu brechen, aber die Zahl klein zu halten. Dies hilft auch bei der Ladezeit.

  • Nicht sicher, ob dies eine gute Idee ist, aber ich möchte die View und ViewModel-Schnittstellen in der gleichen Datei wie das View/ViewModel selbst behalten. Ich mag das, weil das MVVM-Muster viele Dateien erzeugen kann, und das hält die Datei herunter. Der Nachteil ist, dass das Interface und seine Implementierung schwieriger zu trennen sind, aber ich werde das wahrscheinlich nicht tun müssen, und diese Technik stört das Testen nicht, was der andere Vorteil ist.

  • Ansichten neigen dazu, in einen Views-Ordner zu wechseln, dann in einen Ordner für jede View. Der Ordner für jede Ansicht enthält die Ansicht, das ViewModel und den Presenter, falls erforderlich.

  • Erstellen Sie aus der Referenzimplementierung ein Infrastrukturprojekt für alle allgemeinen Klassen, die von Modulen gemeinsam genutzt werden müssen. Die Referenzimplementierung hat mehr Details, aber dies kann für alle Arten von Dingen wie übliche Serviceschnittstellen, Konstanten usw. verwendet werden.