Ce billet a été initialement créé avec l’intention de faire une démonstration sur les façons possibles d’organiser les vues ainsi que les contrôleurs avec ASP.NET MVC. J’avais parti un brouillon avec quelques points comme je fais à l’habitude. Je l’ai laissé mijoter quelques semaines.
Il s’avère que l’inspiration que j’avais initialement pour ce texte s’est évaporée. Pfiou! Il n’y en a plus. Cependant, j’ai tout de même l’intention de produire un texte à ce sujet.
Suite à un brainstorm avec mon équipe lors du démarrage d’un projet, nous avons abordé la question de la façon de structurer les contrôleurs ainsi que les vues du projet. Spécifiquement, il était de déterminer de quelle façon nous allions procéder. À savoir si, d’une part, nous allions de l’avant avec l’un concepts suivants:
- où nous aurions de grosses actions de contrôleur qui ont la responsabilité de tout récupérer et qui envoient les données à des vues pour le rendu
- des actions de contrôleur qui servent à réserver des URL dont les vues sont composées de plus petites actions de contrôleur séparées sur plusieurs vues partielles autonomes
Pour faire simple, j’ai résumé cela à déterminer si nous voulons utiliser @Html.Partial ou @Html.RenderAction dans nos vues. C’est un peu simplet, mais, sommairement, il est possible de le résumer ainsi.
Froidement, sans contexte, la décision relève d’une question de préférence. Personnellement, dans le passé, j’ai opéré dans les deux contextes. Il y a des pour et des contre dans chacun. Cela en revient au contexte dans lequel l’application est développée.
Dans notre situation, il s’agit d’une application avec un nombre fixe de pages. Chacune avec des fonctions bien précise. Les composants communs sont clairement identifiés et appelés à partir du Layout de l’application. À titre d’exemple, dans ces composants, il y a notamment le menu principal, l’entête, le pied de page.
Pour notre part, nous avons opté pour le modèle des grosses actions de contrôleur. Le principal avantage de cela est qu’il est plus facile d’extraire les éléments de logique d’affaire dans les couches de service et de laisser uniquement la tâche à ces contrôleurs l’unique responsabilité d’assembler les différents morceaux pour alimenter leurs modèles respectifs.
L’autre argument pour cette façon de faire est qu’elle instaure une distance entre la logique d’accès et de préparation des données et de l’affichage de celles-ci. Une vue partielle reçoit des données et génère un affichage en fonction de celles-ci. C’est son unique responsabilité. De cette façon, il n’y a pas besoin de se soucier d’où proviennent ses données.
Le principal défi, dans les deux scénarios, est de garder le contrôle sur la dette technique que peut générer un mauvais classement des différentes fonctionnalités de son application. Je surnomme cela l’effet « dossier Shared« . À un moment donné, il y a toujours un dossier de type fourre-tout dans lequel on finit toujours par y déposer certains éléments dont on ne sait pas quoi en faire.
French Coding 
De mon point du vue si le modele peut etre auto suffisant autant tout mettre dedans (et jouer sur la composition), donc html.Patial ou mieux displayFor/editorFor. Cela conduit a un ‘gros’ model.
Pour le coup des grosses methodes de controlleur, dans mon cas tout est deporte dans la business layer: la bl renvoie des modeles, et lors du post on envoie tout le model. Ce qui conduit l’action du controlleur a juste faire la validation des attributs du modele et les redirections.
De plus, de mon point de vue il ne faut surtout pas non plus oublier une des fonctionnalite/limitations de mvc qui est le prefixage des id/name.
Ce qui conduit dans le cas de vue partielles/contenus ajax a manipuler des prefix et/ou d’avoir des editors templates (j’ai eut le cas hier ou je voulais faire un appel ajax pour afficher l’edition d’un sous objet de mon model, mais pouvoir poster le model complet).