Wie sollte die Datei-/Verzeichnisstruktur der Ansicht in ASP.NET MVC aussehen?

Question

Ich bin verwirrt mit, wie Ansichten organisiert sind, und es ist wichtig, dies zu verstehen, da ASP.NET MVC Konventionen verwendet, um alles richtig zu arbeiten.

Unter dem Verzeichnis views gibt es Unterverzeichnisse. Innerhalb dieser Unterverzeichnisse befinden sich Ansichten. Ich nehme an, dass die Unterverzeichnisse Controllern zugeordnet sind und die Controller auf die in ihren Unterverzeichnissen enthaltenen Views wirken.

Gibt es eine sich abzeichnende Erwartung, welche Arten von Ansichten in diesen Verzeichnissen enthalten sind? Sollte zum Beispiel die Standardseite für jedes Verzeichnis index.aspx sein? Sollten die Seiten einer Namenskonvention folgen, wie Create[controller].aspx, List[controller].aspx usw.? Oder spielt dies keine Rolle?

Answer 1

Die Benennung von Ansichtsverzeichnissen und Dateien ist wichtig, da das ASP.NET MVC-Framework bestimmte Annahmen darüber trifft. Wenn Sie sich nicht an diese Annahmen halten, müssen Sie Code schreiben, damit das Framework weiß, was Sie tun. Im Allgemeinen sollten Sie sich an diese Annahmen halten, es sei denn, Sie haben einen guten Grund, dies nicht zu tun.

Schauen wir uns die einfachste mögliche Controller-Aktion an:

    public ActionResult NotAuthorized()
    {
        return View();
    }

Da im Aufruf von View() kein View-Name angegeben wurde, geht das Framework davon aus, dass der View-Dateiname mit dem Action-Namen übereinstimmt. Das Framework hat einen Typ namens ViewEngine, der die Erweiterung liefert. Die Standard-ViewEngine ist die WebFormViewEngine, die diesen Namen nimmt und ein .aspx daran anhängt. Der vollständige Dateiname würde in diesem Fall also NotAuthorized.aspx lauten.

Aber in welchem Ordner wird die Datei gefunden? Auch hier liefert die ViewEngine diese Information. Mit der WebFormViewEngine wird in zwei Ordnern gesucht: ~/Views/Shared und ~/Views/{controller}

Wenn Ihr Controller also AccountController hieße, würde er in ~/Views/Account nachsehen

Es kann jedoch vorkommen, dass Sie sich nicht an diese Regeln halten wollen. Zum Beispiel könnten zwei verschiedene Aktionen dieselbe Ansicht zurückgeben (mit einem anderen Modell, oder so). In diesem Fall können Sie den Namen der Ansicht explizit in Ihrer Aktion angeben:

    public ActionResult NotAuthorized()
    {
        return View("Foo");
    }

Beachten Sie, dass bei der WebFormViewEngine der "View-Name" in der Regel derselbe ist wie der Dateiname, abzüglich der Erweiterung, aber das Framework verlangt dies bei anderen View-Engines nicht.

Sie könnten auch einen Grund dafür haben, dass Ihre Anwendung nach Ansichten und nicht standardmäßigen Ordnern suchen soll. Sie können dies tun, indem Sie Ihre eigene ViewEngine erstellen. Ich zeige die Technik in dieser Blogbeitrag , aber die Typnamen sind anders, da sie für eine frühere Version des Frameworks geschrieben wurde. Die Grundidee ist jedoch immer noch dieselbe.

Answer 2

Was die erwarteten Namen für die Ansichten angeht, so denke ich, dass dies zu den Dingen gehört, die jedes Projekt oder jede Organisation versuchen wird, zu standardisieren.

Wie Sie in Ihrer Frage angedeutet haben, ist es möglich, dass einige dieser Ansichten (oder genauer gesagt, die Aktionen, die sie wiedergeben) allgemein populär werden, wie zum Beispiel die folgenden, die in RoR-Anwendungen, die das REST-Paradigma verwenden, üblich sind:

• /Bestellungen/ (d. h. Index)
• /bestellungen/show/123
• /bestellung/edit/123
• /bestellungen/aktualisierung/123
• /bestellungen/neu
• /bestellungen/erstellen
• /bestellungen/zerstören/123

Die Auswahl/Standardisierung der Ansichten hängt weitgehend davon ab, wie Sie Ihre Anwendung modellieren (um das Offensichtliche zu sagen) und wie feinkörnig Sie vorgehen wollen. Je genauer Sie Ihre Controller auf einzelne Modellklassen (hust... Ressourcen... hust) abbilden, desto kürzer werden Ihre Aktionen in der Regel sein und desto leichter werden Sie in der Lage sein, einem Standardsatz von Aktionen zu folgen (wie im obigen Beispiel).

Ich glaube auch, dass kürzere Aktionen dazu beitragen, dass immer mehr Geschäftslogik in die Modelle selbst verlagert wird, wo sie hingehört.