beratung zur architektur von asp.net mvc-anwendungen

Question

Ich benutze ASP.net MVC jetzt seit etwa zwei Jahren und lerne immer noch, wie man eine Anwendung am besten strukturiert.

Ich wollte diese Ideen, die ich gesammelt habe, in die Runde werfen und sehen, ob sie in der Gemeinschaft "akzeptable" Wege sind, MVC-Anwendungen zu entwerfen.

Hier ist mein Grundlayout:

• DataAccess-Projekt - Enthält alle Repository-Klassen, LINQ-to-SQL-Datenkontexte, Filter und benutzerdefinierte Geschäftsobjekte für Nicht-MS-SQL-DB-Repositories (die von LINQ-to-SQL nicht erstellt werden). Die Repositories verfügen in der Regel nur über grundlegende CRUD-Funktionen für das von ihnen verwaltete Objekt.

• Dienstleistungsprojekt - Enthält Dienstklassen, die Geschäftslogik ausführen. Sie nehmen Aufträge von den Controllern entgegen und teilen den Repositories mit, was zu tun ist.

• UI-Projekt - Enthält Ansichtsmodelle und einige Wrapper um Dinge wie den ConfigurationManager (für Unit-Tests).

• Haupt-MVC-Projekt - Enthält Controller und Views, sowie Javascript und CSS.

Scheint dies eine gute Möglichkeit zu sein, ASP.NET MVC 2-Anwendungen zu strukturieren? Irgendwelche anderen Ideen oder Vorschläge?

Werden Ansichtsmodelle für alle Ausgaben in Ansichten und Eingaben von Ansichten verwendet?

Ich lehne den Weg der Herstellung von Ansichtsmodellen für jedes Geschäftsobjekt, das Daten in der Ansicht anzeigen muss und machen sie grundlegende Klassen mit einem Bündel von Eigenschaften, die alle Zeichenfolgen sind. Dies macht den Umgang mit den Ansichten ziemlich einfach. Die Service-Schicht muss dann die Zuordnung von Eigenschaften aus dem Ansichtsmodell zu dem Geschäftsobjekt verwalten. Dies ist eine Quelle meiner Verwirrung, weil die meisten Beispiele, die ich zu MVC/MVC2 gesehen habe, kein View Model verwenden, es sei denn, man braucht so etwas wie ein Kombinationsfeld.

Wenn Sie die neue Modellvalidierung von MVC 2 verwenden, würden Sie dann das Viewmodel-Objekt validieren und müssten sich nicht darum kümmern, die Validierungsattribute auf die Geschäftsobjekte zu setzen?

Wie testen Sie diese Art der Validierung oder sollte ich nicht testen, dass Validierungsmeldungen zurückgegeben werden?

Danke!

Answer 1

Interessant.

Eine Sache, die ich anders mache, ist, dass ich mein DataAccess-Projekt von meinem Domain-Projekt abgetrennt habe. Das Domain-Projekt enthält immer noch alle Schnittstellen für meine Repositories, aber mein DataAccess-Projekt enthält alle konkreten Implementierungen davon.

Sie wollen keine Dinge wie DataContext in Ihr Domänenprojekt einfließen. Im Anschluss an die Zwiebelarchitektur Ihre Domäne sollte keine Abhängigkeiten von einer externen Infrastruktur haben... Ich würde DataAccess dafür halten, weil es direkt mit einer Datenbank verbunden ist.

Die Abtrennung bedeutet, dass meine Domäne nicht von einem ORM oder einer Datenbank abhängig ist, so dass ich sie bei Bedarf leicht austauschen kann.

Zum Wohl,
Karl

Ps. Wie sieht Ihre Projektabhängigkeit aus? Ich habe mich gefragt, wo ich meine ViewModels unterbringen soll. Vielleicht ist ein separates UI-Projekt eine gute Idee, aber ich bin nicht ganz sicher, wie das funktionieren würde. Wie fließen sie durch die verschiedenen Projektebenen Ihrer Anwendung?