Quelle doit être la structure du fichier / répertoire de vue dans ASP.NET MVC?

Question

Je suis confus avec la façon dont les vues sont organisées. Il est important de comprendre cela car ASP.NET MVC utilise des conventions pour que tout fonctionne correctement.

Sous le répertoire views, il y a des sous-répertoires. Dans ces sous-répertoires se trouvent des vues. Je suppose que les sous-répertoires correspondent aux contrôleurs et que les contrôleurs agissent sur les vues contenues dans leurs sous-répertoires.

Existe-t-il une attente émergente quant aux types de vues contenus dans ces répertoires? Par exemple, la page par défaut pour chaque répertoire devrait-elle être index.aspx? Les pages doivent-elles suivre une convention de dénomination telle que Créer [contrôleur] .aspx, Liste [contrôleur] .aspx, etc.? Ou n'est-ce pas grave?

Answer 1

Les noms de répertoire d'affichage et de fichier sont importants, car la structure ASP.NET MVC émet certaines hypothèses à leur sujet. Si vous ne vous conformez pas à ces hypothèses, vous devez écrire du code pour que le framework sache ce que vous faites. De manière générale, vous devez vous conformer à ces hypothèses, sauf si vous avez une bonne raison de ne pas le faire.

Regardons l'action du contrôleur la plus simple possible:

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

Comme aucun nom de vue n’a été spécifié lors de l’appel de View (), la structure suppose que le nom de fichier de la vue est identique au nom de l’action. La structure a un type appelé ViewEngine qui fournira l’extension. Le ViewEngine par défaut est WebFormViewEngine, qui prendra ce nom et y ajoutera un .aspx. Donc, le nom de fichier complet dans ce cas serait NotAuthorized.aspx.

Mais dans quel dossier le fichier sera-t-il trouvé? Encore une fois, ViewEngine fournit ces informations. Avec WebFormViewEngine, il se présentera dans deux dossiers: ~ / Views / Shared et ~ / Views / {controller}

Donc, si votre contrôleur s'appelait AccountController, il regarderait dans ~ / Views / Account

Mais il peut arriver que vous ne souhaitiez pas suivre ces règles. Par exemple, deux actions différentes peuvent renvoyer la même vue (avec un modèle différent ou autre). Dans ce cas, si vous spécifiez explicitement le nom de la vue dans votre action:

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

Notez qu'avec WebFormViewEngine, le " nom de la vue " est généralement le même que le nom de fichier, moins l'extension, mais le framework ne nécessite pas celui des autres moteurs de vue.

De même, vous pouvez également demander à votre application de rechercher des vues et des dossiers autres que ceux par défaut. Vous pouvez le faire en créant votre propre ViewEngine. Je montre la technique dans this article de blog , mais les noms de type sont différents, car il a été écrit pour une version antérieure du framework. L’idée de base reste toutefois la même.

Answer 2

En ce qui concerne les noms attendus pour les points de vue, je pense que chaque projet ou organisation essaiera de le standardiser.

Comme vous l'avez laissé entendre dans votre question, il est possible que certaines de ces vues (ou plus précisément, les actions qui les rendent) deviennent populaires, comme par exemple celles ci-dessous qui sont courantes dans les applications RoR qui adoptent la Paradigme REST:

• / orders / (c'est-à-dire index)
• / orders / show / 123
• / orders / edit / 123
• / orders / update / 123
• / orders / new
• / orders / create
• / orders / destroy / 123

Le choix / la normalisation des vues dépend en grande partie de la manière dont vous modélisez votre application (pour dire l'évidence) et de la précision avec laquelle vous souhaitez aller. Plus vous associez vos contrôleurs à des classes de modèle individuelles (toux ... ressources ... toux), plus vos actions auront tendance à être courtes et plus facilement vous pourrez suivre un ensemble d'actions standard (comme dans l'exemple ci-dessus). ).

Je pense également que des actions plus courtes aident à intégrer de plus en plus la logique métier du modèle dans les modèles eux-mêmes, là où elle se trouve.