Au fil des années, des améliorations ont été apportées au cadre Web Forms qui tente efficacement de réduire ses couches d’abstraction. Vous avez plus de contrôle sur la sortie générée par les contrôles serveur et sur l'utilisation de l'état d'affichage. Des fonctionnalités telles que la liaison de modèle ont été transplantées à partir du framework MVC introduit plus récemment. Et dans la dernière mise à jour, la prise en charge de l'injection de dépendance a été introduite.

Mais la dernière mise à jour de Web Forms remonte à il y a près d'un an. Il ne fonctionne toujours qu'avec le serveur Web Internet Information Services sous Windows et nécessite l'installation de la totalité du .NET Framework. Les développeurs débutant dans ASP.NET n'apprennent pas les formulaires Web.

Pendant les années, la seule alternative aux développeurs Web pour les développeurs ASP.NET existants était le modèle MVC ( -View-Controller ). L’un des plus gros problèmes avec MVC est l’architecture elle-même. Le développement basé sur le contrôleur de page est assez facile à comprendre. Chaque page a son propre contrôleur, qui peut être la page elle-même, ou dans un objet correspondant séparé tel qu'un «code-behind».

MVC ajoute ce que certains diraient une complexité inutile du processus de développement. Il n'y a plus de mappage univoque entre les URL et les fichiers sur le disque. Si vous voulez faire quelque chose, vous devez ajouter des fichiers à plusieurs endroits différents. Vous devez comprendre l'interaction entre les différentes parties de l'architecture. Par rapport aux modèles de développement centrés sur la page, MVC ajoute beaucoup de cérémonie à la création d’un site Web.

Le cadre de pages Web ASP.NET a été introduit en 2010 dans le cadre de la «pile WebMatrix», en partie pour réduire le nombre de concepts associé à MVC. Bien que Web Pages fournisse un retour au développement basé sur le contrôleur de page, ce n’est pas sans problèmes. Il a été principalement conçu pour faciliter les débutants au développement Web et pour aider les développeurs PHP existants à utiliser la pile Microsoft. En tant que tel, il ne fournissait rien au développeur professionnel cherchant à créer des applications Web robustes, testables et évolutives. Le modèle de développement a encouragé le mélange de la logique de traitement et du balisage HTML dans le même fichier, ce qui permet aux développeurs de réintroduire très facilement les problèmes associés au «code spaghetti» – des difficultés de test et de maintenance. Web Pages a également beaucoup utilisé le type dynamic (introduit dans .NET 4.0) dans le cadre de sa technologie d'accès aux données, qui est assez difficile à déboguer.

Les principaux piliers de la pile WebMatrix étaient obsolètes: l'EDI WebMatrix et le produit de base de données basé sur des fichiers, SQL Server Compact Edition, éliminant efficacement les pages Web en tant que modèle de développement autonome. Mais cela a laissé un héritage – la syntaxe de modèle Razor sur laquelle Web Pages a été construite. Et les fondements de la structure de pages Web existent toujours aujourd'hui, à savoir le moteur de vue de pages Web, qui supplantait le moteur de vue de formulaires Web à partir de MVC 3.0

.NET Core

Puis, a été lancé par .NET Core en 2016, un cadre plus léger conçu pour ne pas dépendre de Windows, afin de pouvoir fonctionner sur d'autres plates-formes. .NET Core est également conçu pour résoudre d’autres problèmes. Sa conception est modulaire, ce qui permet au développeur de choisir les composants dont il a besoin, plutôt que de supporter les frais généraux de tout le monde. Il a été conçu pour supporter beaucoup plus d'extensibilité. L'injection de dépendance est une fonctionnalité de premier ordre, supportant un couplage lâche. Et ses performances sont bien meilleures que celles d’ASP.NET traditionnel.

Lors de son lancement, .NET Core n’offrait que le modèle MVC aux développeurs Web. La version 2.0 d'ASP.NET Core incluait un nouveau modèle de développement centré sur la page appelé Razor Pages. Ce paradigme utilise la syntaxe de modèle Razor (facile à apprendre) et se situe également au-dessus du cadre MVC. Mais vous n’avez besoin de rien savoir de MVC pour travailler avec Razor Pages. Razor Pages est le successeur naturel de Web Forms.

Mappage des fonctionnalités de Web Forms dans le modèle Razor Pages

Le reste de cet article explore les principales fonctionnalités du modèle de développement Web Forms et décrit comment elles sont mappées. au modèle Razor Pages. Je vais décrire les caractéristiques de chacune des fonctionnalités, sans nécessairement aller trop loin dans les détails techniques. Le code est inclus lorsqu'il est utile d'illustrer la forme de base de la fonctionnalité en cours de discussion.

Traitement de la demande: code derrière

Le contrôleur de chaque formulaire Web est son fichier code-behind une classe distincte. fichier qui correspond à un modèle – le fichier .aspx . Le fichier de classe provient de System.Web.UI.Page . La logique générale de traitement de la demande est généralement placée dans la méthode Page_Load . Le verbe utilisé pour faire une demande est déterminé en examinant la propriété IsPostBack de la page:

 public class Index: Page
{
  Void Page_Load protégé (expéditeur d'objet, EventArgs e)
  {
    si (IsPostBack)
    {
      // traite la demande POST
    }
    autre
    {
      // traite la demande GET
    }
  }
} 

L’équivalent de code-behind dans Razor Pages est la classe PageModel qui présente une correspondance individuelle avec sa page de contenu (analogue à la .aspx ). La logique de traitement des demandes est placée dans les méthodes de gestionnaire . Ceux-ci sont nommés, par convention, d'après le verbe utilisé pour la demande qu'ils traitent: OnGet et OnPost (avec leurs équivalents asynchrones):

 public class IndexModel: PageModel
{
  liste publique  Produits {get; ensemble; } = nouvelle liste  ();
  chaîne publique Title {get; ensemble; }

  public vide OnGet ()
  {
    // traite la demande GET
  }

  vide public OnPost ()
  {
    // traite la demande POST
  }
}

Des propriétés publiques ad hoc peuvent être ajoutées à la classe PageModel représentant des éléments pouvant être utilisés dans la page de contenu.

Présentation: Génération d'interface utilisateur

Pages de contenu

Les pages "Rasoir" La page de contenu contient un mélange de HTML et de logique côté serveur, qui est incluse dans la page à l'aide de la syntaxe Razor. La logique côté serveur est généralement limitée à la sortie nécessaire au contrôle, telle que les boucles, les conditions, voire certaines chaînes de mise en forme.

Tout comme les formulaires Web, les pages de contenu Razor ont une directive page qui est requis et placé en haut du fichier. Vient ensuite une directive concernant le modèle qui spécifie le type de données avec lesquelles la page est censée fonctionner (le modèle ). Par défaut, il s'agit du type de données de la classe PageModel correspondante:

 @page
@model IndexModel
... 

Les propriétés publiques et les méthodes de la classe PageModel sont exposées sur la page de contenu via sa propriété Modèle :

 @page
@model IndexModel

 @ Model.Title 

 @if (Model.Products.Any ())
{
  foreach (produit var dans Model.Products)
  {
    
 @ product.ProductName 
  }
} 

Pages maîtres

Le fichier de page maître de Web Forms est utilisé pour centraliser le contrôle de la présentation de toutes les pages qui l'implémentent. Il est généralement déclaré comme faisant partie de la directive Page dans le fichier modèle:

 <%@ Page Title="Home"
         Language="C#"
         AutoEventWireup="true"
         CodeBehind="Index.aspx.cs"
         Inherits="Index"
         MasterPageFile="~/Site.Master" %> 

L’équivalent de Razor au fichier de page maître est le fichier de présentation. Vous pouvez spécifier le fichier de présentation qu'une page Razor doit utiliser en définissant la propriété Layout de la page Razor sur le chemin relatif du fichier spécifié:

 @ {
  Layout = "/shared/_Layout.cshtml";
}

Razor offre une commodité supplémentaire grâce à la forme du fichier ViewImports – un fichier qui affecte toutes les pages du dossier dans lequel il est placé, ainsi que celles de tous les sous-dossiers. Vous pouvez spécifier le fichier de présentation à utiliser par toutes ces pages dans le fichier ViewImports .

Dans une page maître Web Forms, l'emplacement du contenu de la page est défini en plaçant un ou plusieurs . ] Contrôles ContentPlaceHolder . Les contrôles de contenu correspondant aux espaces réservés sont renseignés avec le contenu du formulaire Web. Le modèle habituel consiste à fournir un espace réservé de contenu principal représentant le gros de la sortie du formulaire Web, ainsi que des espaces réservés auxiliaires pour les balises méta, les scripts, les feuilles de style, etc., propres à la page.

Une page de présentation Razor doit avoir un appel à la RenderBody qui est l'équivalent de l'espace réservé de contenu principal dans une page maître. Les espaces réservés auxiliaires sont représentés par des appels à la méthode RenderSection dans la présentation Razor. L'exemple suivant montre une page de mise en page Razor très simple illustrant les appels RenderBody et RenderSection :

 

  
    
    
    
  
  
    

      @RenderBody ()
    
    @RenderSection ("scripts", false)
  

Le contenu principal est rendu dans l'élément

  Edit  

 
   Choisissez-en un 

 @model List 

@foreach (produit var dans le modèle) {
 @ product.ProductName 
...

 tâche publique asynchrone  InvokeAsync ()
{
  Liste  produits = wait productService.GetProductsAsync ();
  retourner Voir (produits);
}

classe publique IndexModel: PageModel.
{
  [BindProperty]
  public Student Student {get; ensemble; }

  public IActionResult OnPost ()
  {
    if (ModelState.IsValid)
    {
      // enregistrer dans la base de données
    }
  }
}