Best Practices für MVC-Architektur [geschlossen]

Meine Frage bezieht sich eher auf die Architektur einer MVC-Anwendung. Beispielsweise wird empfohlen, DI mit dem Repository-Muster zu verwenden, um den Datenzugriff vom Controller zu entkoppeln. Es wird jedoch nur sehr wenig darüber gesagt, wie dies speziell für MVC erfolgen soll. Wo würden wir zum Beispiel die Repository-Klassen platzieren? Sie scheinen nicht modellspezifisch zu sein, da das Modell ebenfalls relativ von den eigentlichen Datenzugriffstechnologien abgekoppelt sein sollte.

Eine zweite Frage betrifft die Strukturierung der Ebenen oder Schichten. Die meisten Beispielanwendungen (Nerd-Dinner, Music Store usw.) scheinen alle einen einstufigen 2-Ebenen-Ansatz zu verwenden (ohne Tests zu zählen), bei dem Controller normalerweise direkt L2S- oder EF-Code aufrufen.

Wenn ich eine Multi-Tier / Layer-Anwendung erstellen möchte, welche Best Practices gibt es in Bezug auf MVC?

asp.net-mvc architecture

— Erik Funkenbusch
quelle

Antworten:

DI wird in ASP MVC mithilfe einer Controller Factory ausgeführt. Diese Factory wird verwendet, um Ihre Controller-Abhängigkeiten aufzulösen.

MvcContrib verfügt über einige Controller Facotry-Implementierungen, die Sie sofort verwenden können. Ich benutze ihre Castle Windsor Implementierung und es funktioniert gut. Ich würde auch vorschlagen, ihre TestHelper-Klasse zu überprüfen. Es hat einige sehr coole Funktionen zum Verspotten von Controller HTTPContext, Sessions, etc .. MVCContrib

Persönlich möchte ich meinen Models eine Repository-Instanz geben, mit der sie arbeiten können. Das Modell macht eine API für das Repository (CRUD) verfügbar. Die Abhängigkeit des Controllers von einem bestimmten Modell wird bei der Erstellung (Konstruktor) injiziert. Diese wird über die Controller Factory injiziert. Dies ist mein Einstiegspunkt in das Objektdiagramm, das von meinem IoC-Container verwaltet wird.

Wo würden wir zum Beispiel die Repository-Klassen platzieren?

Sie gehören in das Modell; Sie sind das In-Application-Modell.

Wie strukturiere ich die Ebenen? Wenn ich eine Multi-Tier / Layer-Anwendung erstellen möchte, welche Best Practices gibt es in Bezug auf MVC?

Ebenen Stellen physische Codetrennungen dar. Ebenen stehen für logische Trennungen. Die Schichten (wie sie derzeit sind) funktionieren gut für MVC. Abhängig vom Umfang der Geschäftslogik kann diese entweder in Ihrem Controller oder in einer separaten Baugruppe platziert und vom Controller während des Anforderungszyklus verwendet werden.

— George Stocker
quelle

Sie schlagen also vor, dass sie in das UI-Projekt einer mehrschichtigen Anwendung aufgenommen werden sollen?

— Erik Funkenbusch

@Mystere Man Wenn es nicht gigantisch ist, sollten sie in das Projekt gehen, das Ihre MVC-Anwendung hostet. Insbesondere würde die Geschäftslogik in den Controller eingehen und jede Aktion würde ihre eigene Logik haben. MVC ist nicht nur ein Muster für die Benutzeroberfläche. Deshalb bin ich mit Ihrer Behauptung nicht einverstanden, dass es sich um ein "UI-Projekt" handelt. Ist es nicht. Es ist ein MVC-Projekt, das als ViewAbschnitt (es gibt Ihre Benutzeroberfläche).

— George Stocker

Ok, vielleicht habe ich das schlecht formuliert. Stimmen Sie jedoch nicht zu, dass die Ansichtsebene die Datenbank nicht manipulieren sollte? Und wenn Sie die Repository-Klassen in das Modell einfügen, kann die Ansicht dies tun.

— Erik Funkenbusch

In einer kleinen MVC-Anwendung ist die "Ebene" der Benutzeroberfläche einfach der Ordner, in dem sich die Ansichten befinden. In einer größeren Anwendung kann es sich um ein eigenes Projekt handeln. Wenn es sich um ein eigenes Projekt handelt, wird es mit dem Controller koordiniert und der Controller kann sich bei Bedarf in den BusinessLayer einbinden. Niemand außerhalb des Controllers müsste überhaupt wissen, dass es die Business-Schicht gibt. Ich denke, Sie denken automatisch, dass es sich um separate Projekte handelt, aber das muss nicht so sein.

— George Stocker