ASP.Net MVC Voir la structure

Question

Je viens de terminer le didacticiel Nerd Diner de Scott Gu. Je l'ai trouvé très utile car il a non seulement enseigné les bases de ASP.Net MVC, mais aussi comment l'utiliser avec des dépôts, Validation, tests unitaires, Ajax, etc. Très bien, mais toujours gérable.

Cependant, je suis curieux de connaître sa structure du site:

Plus précisément, il a utilisé ce point de vue strucuture pour chaque objet:
/ModelObject/Edition/
/ModelObject/Créer/

a ensuite extrait le éléments communs entre les deux points de vue et les mettre dans un partiel. Je comprends la logique, mais il semble que cela conduirait à "voir l'explosion" si vous avez un nombre même modéré de tables dans votre base de données. Scott est vraiment bon, donc je suppose que sa structure est bonne. Mais j'aimerais savoir pourquoi.

Merci!

[Editer des précisions]

je me rends compte que beaucoup de fois qu'il est nécessaire pour qu'il y ait de multiples actions (et vues) pour gérer les différences de créer et de modifier. C'est le cas de l'édition et de la création très simples, où la seule différence entre les deux actions est dans un cas le modèle a un identifiant et doit être mis à jour, et dans l'autre cas le modèle ne l'est pas, il doit donc être inséré.

Dans ce cas, la violation de la règle "Dumb View" est-elle en utilisant la même vue pour gérer les deux cas qui vont causer des problèmes majeurs?

Answer 1

La structure de vue est basée sur les contrôleurs, pas directement sur le modèle. Dans la méthodologie Mvc, vous devriez avoir une vue pour chaque action (chaque méthode publique, essentiellement) dans un contrôleur. Les actions du contrôleur ne doivent pas correspondre directement à chaque table dans la base de données, mais il existe probablement une sorte de relation directe entre le nombre de tables dans la base de données et le nombre de contrôleurs et de vues. Les contrôleurs sont plus haut niveau

Il est standard pour avoir des actions de type CRUD sur le contrôleur, quand ils sont applicables:

• Index: liste des articles
• Détails: voir un élément spécifique
• Edit: modifier un élément
• Créer: nouvel élément
• supprimer: supprimer un élément

Chacune de ces actions nécessitera une vue (et parfois plus d'une). Donc, oui, vous pouvez collecter un grand nombre de vues si c'est une application volumineuse. La façon de minimiser le code est:

• Extrait des fonctionnalités partagées à une vue partielle, à maintenir les vues d'action aussi petite et simple que possible
• Gardez les vues et les contrôleurs simples de sorte qu'ils sont faciles à entretenir
• Utilisez AJAX pour mettre en œuvre plus de fonctionnalités dans une vue

Il est important de souligner que toute grande application va avoir beaucoup de formes. Que ce soit Mvc ou Web Forms, s'il y a beaucoup de données à utiliser, il y aura beaucoup de formulaires nécessaires pour le faire.

Answer 2

Si vous avez une expérience en tant que développeur de webmestres asp.net, votre réponse est naturelle. Il y a plusieurs questions, cela dépend du point de vue. Au début, avec asp.net-mvc, nous n'avons pas de contrôles serveur entièrement équipés qui font beaucoup de choses pour nous, sans une réelle conscience de ce qu'ils font. Maintenant, vous devez taper plus de code et avoir des yeux comme un chirurgien sur html.Cette façon je peux trouver une question raisonnable pour "voir l'explosion" Autres projets suivent plus ou moins cette structure, voir le projet par Rob Conery: Mvc Storefront

PS: "contrôleurs Skinny, modèle Fat ... Voir Dumb"

[réponse de mise à jour à la clarification]

Mhh .. Je pense qu'il n'y a pas de violation de "vue stupide". L'important est que toutes les vues n'ont rien à voir avec le code dans la couche logique métier ou dans votre modèle. Vous pouvez avoir un bouton "Enregistrer", c'est le contrôleur doit savoir quelle action doit être exécutée, insérer ou mettre à jour.

Answer 3

Il est vrai que cela peut en effet se prêter à beaucoup de vues. Cependant, j'ai trouvé que dans mes applications de la vie réelle, je vais avoir un certain nombre de tables que je n'ai pas une corrélation 1: 1 aux opérations CRUD. Alors que j'ai certainement des données qui vont dans ces tableaux, j'ai trouvé que la plupart du temps une vue présente des données d'au moins deux sinon trois ou plus de tables. Comme pour toutes les autres applications, vous devez savoir ce que vous recherchez afin de pouvoir planifier les choses. Toute application de grande taille va nécessiter un peu de planification à l'avance (ce qui inclurait l'analyse du nombre de vues/contrôleurs pour MVC).

Seules les petites applications peuvent être regroupées en fonction de vos connaissances et de votre expérience.

Answer 4

En plus de réflexion, ce que je pense:
La combinaison de l'édition/créer des vues serait facile sur des modèles simples, car

- Mêmes propriétés affichées
- validation Même

MAIS cela vous forcerait à

- gérer à la fois la mise à jour et l'insérer dans la même action
- utiliser une instruction de contrôle en vue de déterminer quelle vue l'action est utilisée pour mettre à jour

Les deux options semblent laids et inutiles quand il est si facile à utiliser actions séparées et vues séparées avec le code commun extrait dans un partiel.