Razor Pages est une nouvelle fonctionnalité introduite dans Core.Net 2.0. Razor Page est une page composée d'une mise en page standard (Affichage) et d'une classe backend. Dans un sens, il ne ressemble à des formulaires Web que sans support dynamique. L'avantage d'une telle solution est évident - nous nous débarrassons d'une couche inutile - le modèle de page (un modèle de données sous la forme, par exemple, d'Entity est en lui-même). Le backend de page est à la fois un contrôleur et un modèle - OOP classique - encapsulant des données et des méthodes de travail avec eux dans un seul objet. Au final, le modèle de page n'est qu'une classe, il n'y a aucune raison pour que le contrôleur ne puisse pas être cette classe.
En d'autres termes, Razor Pages est une solution Web plus saine que MVC, nous traitons maintenant du concept traditionnel et logique de «page» et non des contrôleurs et des modèles dispersés tout au long du projet. Mais comme .NET se développera en direction de Core.Net, il est peu probable que Razor Page apparaisse dans le cadre standard, malgré le fait que dans les années à venir, la plupart des projets resteront sur .NET standard. Néanmoins, il est possible de représenter la fonctionnalité de Razor Pages sur un framework standard.
La solution semble en fait assez banale - vous devez ajouter la conception suivante au contrôleur:
protected override void OnActionExecuting(ActionExecutingContext Context) { UpdateModel(this); }
La méthode OnActionExecuting est un événement du cycle de vie qui est appelé avant l'exécution de la méthode du contrôleur (c'est-à-dire le gestionnaire de requêtes - Action).
UpdateModel lie directement les paramètres de demande aux propriétés du modèle - dans ce cas, les propriétés de la classe de contrôleur.
Une commodité supplémentaire - il n'est désormais plus nécessaire d'accepter explicitement les paramètres de type Model ou de tout autre. Bien que rien n'empêche cela, si le paramètre est un simple identifiant qui sera utilisé uniquement comme variable locale, la liaison de paramètres en tant que propriétés du contrôleur est nécessaire, par exemple, si vous souhaitez assurer la persistance de la page, qui sera discutée plus loin.
Un exemple simple:
Nous avons le formulaire de connexion habituel avec deux champs.
Il ne sert à rien de baliser; je ne donnerai que le code du contrôleur
public class AccountController : Controller { public string username{ get; set; } public string userpass{ get; set; } [HttpPost] public ActionResult OnLogin( ) {
Comme vous pouvez le voir, au moment où l'événement est déclenché, les données d'entrée sont déjà liées et prêtes à l'emploi.
Bien sûr, nous devons garder à l'esprit que nous devons maintenant retourner en tant que ActionResult le contrôleur également, et dans le modèle écrire le nom de la classe de contrôleur - tel que @Model AccountController.
Grâce à cette solution, la tâche de maintien de l'état de la page entre les requêtes est également simplifiée. Disons que vous avez une page avec un certain tableau, un filtre trié par colonnes et une pagination.
Vous cliquez sur le filtre, le modèle revient à la vue et tout va bien, mais lorsque vous cliquez sur le tri, le filtre se réinitialise naturellement. Le paginateur réinitialise le tri et le filtre. Dans WebForms, l'état de la page a été enregistré automatiquement, dans MVC, vous devez appliquer diverses décisions lourdes, par exemple, coller tous les paramètres et les piloter pour chaque demande, c'est-à-dire que vous devez suspendre tous les paramètres qui précèdent du filtre sur le lien de tri.
De telles difficultés sont l'une des raisons de la folie SPA et autre javascript avec le glissement de la logique et des données dans le navigateur avec les freins du navigateur qui en résultent (en particulier les appareils mobiles), les pages sautant et saccadées pour chaque mouvement de la souris et augmentant la complexité et le coût du travail - car le backend est tout de même écrire sous une forme ou une autre, emballer les données envoyées via ajax, plus l'enfer callbac, les complications du débogage et ainsi de suite, et tout cela sans avantage pratique pour les visiteurs du site qui ne se soucient pas de savoir comment Page Isana.
La solution la plus logique consiste à enregistrer l'état de la page dans la session. Étant donné que nous avons tous les paramètres nécessaires sous la forme de propriétés de contrôleur, il suffit de redéfinir la méthode OnActionExecuted, qui est appelée après le traitement de la demande, et de regrouper les propriétés nécessaires dans la session (la clé de session doit évidemment pointer vers le nom du contrôleur).
protected override void OnActionExecuted (ActionExecutedContext Context) {
Les paramètres sont restaurés à partir de la session dans le constructeur du contrôleur ou avant d'appeler UpdateModel (this). Lorsqu'une demande arrive, par exemple des tris, les nouveaux paramètres changeront et le reste restera intact et la vue sera affichée sous la même forme qu'elle a été envoyée.
Une telle solution a un avantage supplémentaire - par exemple, l'utilisateur a trié le tableau et a décidé de modifier un élément en ouvrant une autre page pour cela. Naturellement, il souhaite revenir à l'état de la liste qu'il a quitté, et puisque l'état de la page est dans notre session, la page sera restaurée automatiquement. Il n'est pas nécessaire, comme c'est souvent le cas, de transférer la «boulette» entière des paramètres vers la page d'édition et vice versa. S'il n'est pas nécessaire d'enregistrer l'état entre les pages, l'état de la page peut être stocké non pas dans une session, mais dans TempData.
J'espère que ces «hacks de la vie», bien qu'ils semblent triviaux, seront utiles aux débutants jusqu'à ce qu'ils espionnent Internet pour des solutions plus inconfortables et encombrantes et décident qu'il n'y en a pas d'autres.