Les liens de la semaine – Édition #170

Développement

.NET

Technologie

Web

 

Publicités

Je me pose la questions à toutes les fois. Quelle structure opter pour ses vues et contrôleurs avec ASP.NET MVC?

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.

Les liens de la semaine – Édition #169

Développement

.NET

Technologie

Web

Science et autres