2016-06-13 7 views
0

Ich versuche eine neue Anwendung zu erstellen und in Schwierigkeiten zu laufen, um es sauber zu machen.3-Tier-Architektur mit mehreren Präsentationsebene

Die Idee war, es so zu machen:

  • WebSite1 (Presentation Layer)
    • XAML Seiten
    • -Code hinter Seiten
    • Was wir PageViewModel (Objekt, das angibt, rufen Seitenmodell)
  • WebSite2 (Presentation Layer)
    • Gleiche wie website1
  • WebSiteX (Presentation Layer)

    • Gleiche wie Website 1
  • Geschäft Projekt

    • Service (Werden von Code hinter Seiten aufrufe sein, DAL Objekts in dem Ansichtsmodell lesbar Website-Transformation)
    • Viewmodel (Repräsentiert reales Objekt kann die Verwendung in mehreren Seiten/Websites sein)
  • DAL Projekt

    • Manager (Call-by-Dienste, Rückkehr DAL-Objekt)
    • DAL (Zugang zur Datenbank oder aus anderen Quellen)

Meine Viewmodels werden in einem seperaten Projekt gespeichert und können Wird bei Bedarf in verschiedenen Websites verwendet.

Ich fühle mich schmutzig über die Tatsache, dass die Präsentationen Regeln (wie dies eine Zahl sein sollte oder dies erforderlich ist) in der Business-Schicht (Attribute innerhalb der ViewModels) gespeichert werden. Es ist auch möglich, dass zwei Websites dasselbe Objekt verwenden, jedoch unterschiedliche Präsentationsregeln (in einem Fall nicht in dem anderen).

Der einzige andere Weg, den ich sehe, ist, die Dienste und die ViewModels innerhalb jeder Website zu setzen, aber wenn sie ähnliche Objekte verwenden, wird der Code dupliziert.

Wie würden Sie tun?

Danke fürs Lesen.

Antwort

0

Ich denke, dies könnte eine gute Instanz für die Vererbung sein. Erstellen Sie eine Basisinstanz Ihrer PageVM-Klassen und überschreiben Sie das Verhalten in den verschiedenen Websites.

Versuchen Sie, Dinge wie "requiredness" in separate Methoden zu trennen, die überschrieben werden können, indem Sie sie in der Basisinstanz möglicherweise als abstrakt deklarieren, sodass Sie gezwungen sind, diese Logik in der implementierenden Version zu definieren.

Die schwierigeren Bits werden die Konstruktion der PageVM-Objekte sein, und Sie möchten wahrscheinlich Factory- oder Builder-Muster untersuchen, damit Ihre UI-Projekte die benutzerdefinierten PageVM-Objekte erstellen.

+0

Danke für Ihre Antwort. Vielleicht können die ViewModels in ein "globales Projekt" definiert werden und bei Bedarf mit bestimmten Einreichungsregeln in jede WebSite übernommen werden. Es sieht immer noch wie Duplikation aus, denn in vielen Fällen werde ich das gleiche Objekt haben, aber es ist wahrscheinlich sauberer. –

0

Ich denke, dass Präsentationsregeln in PageViewModel sein können oder Sie können Validierungsregeln haben, wenn Sie von PageViewModel zu BusinessObjects transformieren (Sie rufen sie View Models an).

Auch, was Sie bereits erwähnt haben, funktionieren würde

Die einzige andere Art, wie ich sehe, ist die Dienste und die Viewmodels innerhalb jeder Websites zu setzen, aber wenn sie den Code ähnliche Objekte verwenden dupliziert werden.

Ich würde doppelte ViewModels und nicht Services halten. Ja, der Code ist doppelt, aber das gibt mir die Freiheit und wird zielgerichtet sein, separate Websites separat zu unterhalten, trotz des zugrunde liegenden Geschäftsmodells.

+0

Danke für Ihre Antwort. Die Validierungsregeln sind Attribute wie [Erforderlich] über den Eigenschaften von ViewModel. Auf diese Weise kann die Validierung vor der Validierung des Formulars durchgeführt werden. Die Transformation von ViewModel in BusinessObjects kann auch Validierungsregeln enthalten, aber es ist ein bisschen spät im Prozess. Duplizierung ist wahrscheinlich die Option, die ich wählen werde, aber ich mag die Idee nicht, das gleiche Objekt mit dem gleichen "Transformationscode" an mehreren Stellen zu haben. –