Fermer

octobre 1, 2020

Création de votre prochaine application Web avec ASP.NET Core


L'un des mérites d'ASP.NET Core est de savoir comment il parvient à fournir un certain nombre de solutions intégrées pour différents cas d'utilisation sans gêner.

Dans ce billet de blog, nous examinons certaines de ces solutions intégrées dans ASP.NET Core (MVC, Razor Pages, Blazor), à quoi chacune est-elle le mieux adaptée et comment nous pourrions les utiliser pour créer une application fictive supercar.fans.

Contexte

ASP. NET MVC était un framework Web open source inspiré de Ruby on Rails pour .NET, sorti en 2009. (Fait amusant: Scott Guthrie a écrit les premières centaines de lignes de ce framework lors d'un vol.) En 2014, ASP.NET L'équipe a commencé à réécrire ASP.NET MVC pour le rendre plus convivial pour le cloud et, ce faisant, a fini par le rendre multiplateforme. Environ deux ans plus tard, en 2016, ils ont été publiés en tant que ASP.NET Core 1.0, avec le multiplateforme .NET Core 1.0.

Aujourd'hui, ASP.NET Core est à 3.1 et cibles . NET Core 3.1 par défaut. Par ciblant .NET Core 3.1, toutes les API disponibles dans .NET Core 3.1 sont mises à la disposition des utilisateurs d'ASP.NET Core 3.1.

ASP.NET Core Framework

ASP.NET Core est un Framework d'application Web qui jette les bases de la création d'applications Web dans .NET Core. Il fournit un support prêt à l'emploi pour injection de dépendances journalisation configuration etc., fournit un contrôle complet du pipeline de requêtes via son middleware API, et bien plus encore.

Une application Hello World très basique dans ASP.NET Core pourrait ressembler à:

 public   static   class   Program 
 { 
     public   static   void   Main  ()   = > 
        WebHost .  CreateDefaultBuilder  ()  
            .  Configure  ( app  = > 
             {
                app .  UseRouting  () ; 
                app .  UseEndpoints  ( endpoints  = > 
                 {
                    endpoints .  MapGet  ( "/"   async  context  = >  
                         wait  context  .  Réponse .  WriteAsync  ( "Hello World" ) ) ; 
                } ) ; [19659029]} ) 
            .  Build  ()            
            .  Run  () ;             
} 

It crée un WebHost et Configurez-le pour utiliser le middleware de routage puis spécifie ce qu'il faut faire lorsqu'une requête HTTP GET à / est reçu.

ASP.NET Core fournit également trois principaux frameworks de niveau supérieur:

  1. MVC
  2. Razor Pages
  3. Blazor

Chacun de ces cas d'utilisation différents. Et comme ils sont ajoutés à l'application en tant que middleware, ils peuvent facilement coexister dans la même application, ce qui nous permet d'utiliser le bon outil pour le travail.

ASP.NET Core MVC

Ceci est très similaire à l'ancien ASP.NET MVC dans le concept .

Nous avons un tas d'actions de contrôleur (méthodes C #) qui acceptent et traitent les requêtes HTTP, et retournent des vues Razor.

Voici un exemple Hello World:



 public   class   HelloWorldController  :  ] Manette
 {
     [ HttpGet  ( "/" ) ] 
     public  IActionResult  Bonjour  ()   = >   Voir  () ; 
} 


 < p >  Hello World!  < /  p >  

Nous pouvons également utiliser MVC sans vues Razor pour les API. L'exemple suivant renvoie à la place un objet JSON:



 [ ApiController ] 
 public   class   HelloWorldController  :  ControllerBase
 {
     public  IActionResult  Bonjour  ()   = >  
         Ok  ( new   { ] Message  =   "Hello World"  } ) ; 
} 

Écrire des API Web à l'aide de MVC est une joie. Cependant, pour les pages Web, MVC peut se sentir comme une cérémonie malgré la flexibilité qu'il offre.

Si vous essayez de créer une API Web, que ce soit pour la consommation publique ou pour vos applications client, MVC est l'outil parfait pour le travail. 19659123] Pages Razor ASP.NET Core

Ceci suit un modèle de page, similaire à PHP en un sens. Vous avez un tas de fichiers Razor ( .cshtml ) pour les pages Web réelles et des fichiers C # facultatifs ( .cs ) pour la logique backend (comme le traitement de l'entrée d'un formulaire). [19659005] Une page Hello World Razor pourrait ressembler à:


 @page

 < p >  Bonjour tout le monde!  </  p >  

Pas besoin d'actions de contrôleur, comme dans MVC. Supposons que nous devions interroger la base de données pour afficher une liste d’éléments. Nous pourrions faire quelque chose comme:


 @page
@inject IItemRepository db
@ {
    var items = attendre db.GetItems ();
}

 < ol > 
@foreach (élément var dans les éléments)
{
     < li >  @ item.Title  </  li > 
}
 </  ol >  

Le principal avantage de Razor Pages par rapport à MVC est la facilité avec laquelle il est conçu pour les développeurs lorsqu'il s'agit de créer des pages Web. Supposons que vous deviez ajouter une nouvelle page avec un formulaire de contact à votre application. Avec Razor Pages, il vous suffit d'ajouter un seul fichier Contact.cshtml pour le balisage et un fichier Contact.cshtml.cs pour traiter le formulaire soumis.

La seule mise en garde est lorsque la page Razor doit faire une requête Ajax (par exemple pour valider un champ côté client). Dans ce cas, il est plus simple d'héberger l'API de validation avec MVC.

Autres technologies prises en charge

Appels de procédure distante gRPC (gRPC)

gRPC est un appel de procédure distante (RPC) hautes performances indépendant du langage ), particulièrement utile dans les environnements de microservices. Microsoft Docs a une page décrivant les scénarios où gRPC a un sens . ASP.NET Core prend en charge les applications gRPC.

SignalR

SignalR fournit une abstraction sur un ensemble de protocoles de transport y compris WebSockets pour les applications .NET pour envoyer des notifications en temps réel à le navigateur. SignalR peut être utilisé pour implémenter des fonctionnalités telles que les notifications de tableau de bord lorsque le serveur doit lancer une opération sur le client.

ASP.NET Core Worker Services

C'est comme une application console naïve qui s'exécute sur le serveur. Il peut être utilisé comme service d'arrière-plan (par exemple pour traiter des travaux de longue durée), ou pour effectuer de petites tâches sur le serveur qui s'exécutent jusqu'à la fin (par exemple pour amorcer des données de test). Les nœuds de calcul sont censés être déployés indépendamment d'une application ASP.NET, mais si vous souhaitez qu'elle fasse partie de l'application ASP.NET, vous pouvez enregistrer les IHostedService respectifs auprès de la DI.

Blazor [19659004] Depuis le site Web :

Blazor vous permet de créer des interfaces utilisateur Web interactives en utilisant C # au lieu de JavaScript. Les applications Blazor sont composées de composants d'interface utilisateur Web réutilisables implémentés à l'aide de C #, HTML et CSS. Le code client et serveur est écrit en C #, ce qui vous permet de partager du code et des bibliothèques.

ASP.NET Core a deux implémentations pour Blazor: l'une qui s'exécute sur le serveur mais peut communiquer de manière transparente avec le navigateur client, et l'autre qui s'exécute sur le navigateur comme n'importe quel autre SPA.

Toutes les implémentations de Blazor suivent le même modèle de composant – les différentes implémentations permettent simplement de rendre les composants de différentes manières. Plus d'informations à ce sujet dans un instant.

Blazor Server

Les composants Blazor Server s'exécutent sur le serveur et utilisent une connexion SignalR pour injecter des mises à jour DOM dans le navigateur client.

Ce qui distingue Blazor des SPA traditionnels est comment il parvient à relier le client et le serveur d'une manière qui n'a pas été possible jusqu'à présent. Par exemple, un composant Blazor qui a besoin d'afficher certaines données peut extraire les données de la base de données sur le serveur et les afficher sur le navigateur client, ce que les composants Vue ou React n'étaient pas censés faire.

Le code suivant sera affichez d'abord «Chargement des éléments…», puis remplacez ce div par une liste d'éléments après que Items soit renseigné à partir de la base de données :

 @page " / "
@inject IItemRepository db

@code {
    private IReadOnlyList  < Item > ? Objets {get; ensemble; }
}

@if (Items est nul)
{
     < div >   < p >  Chargement des éléments ...  </  p > [19659098]  </  div > 
}
autre
{
     < ol > 
    @foreach (élément var dans Items)
    {
         < li >  @ item.Name  </  li > 
    }
     </  ol > 
}

@code {
    Tâche async de remplacement protégé OnInitializedAsync ()
    {
        Items = attendre db.GetItems ();
    }
}

Blazor WebAssembly

Blazor WebAssembly vous permet d'exécuter du code .NET dans le navigateur en utilisant le standard WebAssembly ouvert. Ceci a été récemment publié après avoir passé un long moment en aperçu, et est enfin prêt pour la production.

Contrairement à Blazor Server, il est complètement séparé du serveur, et aura besoin d'un backend API Web comme tout autre SPA le ferait. Si l'API est écrite en C #, elle offre une excellente opportunité de réutilisation du code, en particulier en ce qui concerne les ViewModels de requête / réponse et la logique de validation.

Voici la version WebAssembly de l'exemple précédent:

 // The Action MVC qui renvoie les éléments du serveur
[HttpGet("/items")]
Tâche publique async  Get () =>
    Ok (attendez db.GetItems ());
 @page "/"
@inject HttpClient http

@code {
    private IReadOnlyList  < Item > ? Objets {get; ensemble; }
}

@if (Items est nul)
{
     < div >   < p >  Chargement des éléments ...  </  p > [19659098]  </  div > 
}
autre
{
     < ol > 
    @foreach (élément var dans les éléments)
    {
         < li >  @ item.Name  </  li > 
    }
     </  ol > 
}

@code {
    Tâche async de remplacement protégé OnInitializedAsync ()
    {
        Items = wait http.GetFromJsonAsync <Liste  < Item > > ("/ items");
    }
}

Nous devions exposer une API GET: / items utilisant MVC et lui faire une requête HTTP GET à partir du client (application Blazor). Mais nous pourrions réutiliser la classe Item sans avoir besoin d'en avoir une copie dans le serveur et dans l'application cliente. En échange du petit effort supplémentaire par rapport à Blazor Server, nous pouvons exécuter C # de manière native sur le navigateur.

Bien que cela ne remplace pas complètement JavaScript dans le navigateur, il remplace les frameworks SPA comme Angular, Vue.js, etc. Les applications Blazor WebAssembly, comme toute autre application SPA, peuvent être déployées sur un serveur Web statique. Tout sur le client permet également de créer des Progressive Web Apps avec une prise en charge complète hors ligne.

Le modèle de composant Blazor

Ce qui rend Blazor puissant, c'est son modèle de composant. Vous créez l'application basée sur un modèle commun et le moteur de rendu gérera les détails. Cela explique pourquoi les exemples de code Blazor Server et Blazor WebAssembly ci-dessus se ressemblent tellement, malgré le fait qu'ils fonctionnent différemment.

Jetez un œil à l'extrait ci-dessous qui utilise la grille de Telerik UI pour Blazor -vue. Cela fonctionnera également sur tous les supports de Blazor Platform Telerik.

 @page "/"
@inject produits IProductService

 < TelerikGrid   Data  =  @GridData   EditMode  =  " @ GridEditMode.Inline "   Hauteur  =  " 500px " 
              Pageable  =  " true "   PageSize  =  " 15 " 
              OnCreate  =  " @CreateHandler "   OnDelete  =  " @DeleteHandler "   ] OnUpdate  =  " @UpdateHandler "  > 
   < GridToolBar > 
     < GridCommandButton   Command  =  " Add "   Icon  =  " add  " >  Ajouter un produit  </  GridCommandButton > 
   </  GridToolBar > 
   < GridColumns > 
     < GridColumn   Field  =  @nameof (Product.ProductName)   Title  =  " Product Name "    /> 
     < GridColumn   Field  =  @nameof (Product.UnitPrice)   Title  =  " Unit Price "  > 
       < Modèle > 
        @ (String.Format ("{0: C2}", (context as Product) .UnitPrice))
       </  Modèle > 
     </  GridColumn > 
     < GridColumn   Field  =  @nameof (Product.UnitsInStock)   Title  =  " Unités en stock "    /> 
     < GridCommandColumn > 
       < GridCommandButton   Command  =  " Edit "   Icon  =  " edit  " >  Modifier  </  GridCommandButton > 
       < GridCommandButton   Command  =  " Delete "   Icon  =  " delete  " >  Delete  </  GridCommandButton > 
       < GridCommandButton   Command  =  " Save "   Icon  =  " save  "  ShowInEdit  = "  true  " >  Update  </  GridCommandButton > [19659098]
       < GridCommandButton   Command  =  " Cancel "   Icon  =  " cancel  "  ShowInEdit  = "  true  " >  Cancel  </  GridCommandButton > [19659098]
     </  GridCommandColumn > 
   </  GridColumns > 
 </  TelerikGrid > 

@code {
    Liste publique  < Produit >  GridData {get; ensemble; }

    protected override void OnInitialized ()
    {
      GridData = produits.GetProducts ();
    }

    Private void CreateHandler (args GridCommandEventArgs)
    {
        // créer un produit ici
    }

    Private void DeleteHandler (args GridCommandEventArgs)
    {
        // supprimer le produit ici
    }

    Private void UpdateHandler (args GridCommandEventArgs)
    {
        // mettre à jour le produit ici
    }
}

Le modèle de composant signifie également que l'équipe Blazor peut créer des moteurs de rendu supplémentaires pour différents scénarios, sans que nous ayons à apprendre un nouveau cadre pour chacun d'eux. Il faut en particulier mentionner Mobile Blazor Bindings . Il est actuellement en préversion expérimentale, mais vous pouvez toujours l'essayer.

L'application supercar.fans

Dans cette section, nous allons examiner une application fictive et comment nous pourrions la créer en utilisant ASP.NET Core . Afin de rester sur le sujet, nous n'aborderons pas d'autres problèmes comme la persistance, la mise en cache, etc. ou des technologies non spécifiques à ASP.NET comme les fonctions sans serveur.

https://supercar.fans est un site pour les fans purs et durs de supercar. Il regroupe les actualités liées aux supercars provenant de diverses sources à l'aide de leurs flux RSS et vous permet de les parcourir en un seul endroit. Les réviseurs de contenu du site travaillent dur dans les coulisses pour s'assurer que vous ne voyez que les nouvelles, les fuites et les rumeurs les plus fiables.

Sur la base de la copie ci-dessus, nous pouvons déduire trois aspects différents de l'application qui pourraient éventuellement être abordés différemment:

  1. Syndication RSS
  2. L'interface du réviseur de contenu
  3. Le site Web public destiné à l'utilisateur final

 Schéma de principe de supercar.fans

Nous avons besoin d'un travail d'arrière-plan qui vérifie un tas de flux RSS pour le nouveau contenu, à un intervalle prédéfini, par exemple une fois toutes les heures. Nous pouvons le faire en utilisant un Worker ASP.NET Core.

Et nous pourrions commencer en hébergeant simplement le worker directement dans notre application ASP.NET Core. Il peut être remanié lorsque le besoin de mise à l'échelle se fait sentir.

Interface du réviseur de contenu

Ce type d'interface d'administration a généralement un nombre limité d'utilisateurs par rapport au site Web public – ce qui signifie que l'utilisation est prévisible, et donc l'échelle est rarement un problème à résoudre. Et si vous envisagez l'application d'un point de vue commercial, c'est également l'une de ces choses qui devraient idéalement nécessiter peu de maintenance, tout en étant fonctionnelle et fiable.

D'après ce que nous avons vu avec ASP.NET Core, Blazor Server serait le candidat idéal pour quelque chose comme ça. Rapide à développer et facile à entretenir.

Le site Web public

Il y a deux façons de procéder:

  1. Razor Pages: Razor pages signifierait que vous déposeriez un tas de Razor ( .cshtml ), et vous êtes prêt à partir. Encore une fois, peu d'entretien. Je choisirais ceci si le premier chargement est important.
  2. Blazor WebAssembly + MVC: Nous utilisons des composants Razor ( .razor ) qui fonctionnent sur le navigateur. Et comme nous l'avons vu plus tôt dans l'article, cela peut également nécessiter peu de maintenance puisque nous pouvons réutiliser les ViewModels utilisés par les contrôleurs API.

Si vous avez remarqué, la décision ici n'a pas à voir avec Razor Pages ou Blazor WebAssembly en soi, mais avec si nous souhaitons que les «vues» soient exécutées sur le serveur (Razor Pages) ou sur le client (Blazor WebAssembly).

The Future of .NET

The original .NET Framework 1.0 est sorti en février 2002. En 2016, .NET Core a vu le jour. Cela a créé une sorte de division entre les deux cadres, car bien qu’ils soient similaires, ils n’étaient pas les mêmes. Depuis la publication initiale, l'équipe .NET a migré environ 120 000 API à partir du .NET Framework d'origine et a proposé le .NET Standard pour permettre un meilleur partage de code.

Aller de l'avant, au lieu d'avoir un .NET Full Framework séparé et un .NET Core séparé, la prochaine version de .NET Core 3.1 sera le nouveau .NET 5. Les utilisateurs du .NET Framework complet sont encouragés (mais pas obligés) à migrer vers .NET 5. Et l'année prochaine, avec la sortie de .NET 6, nous allons également fusionner Mono avec lui.

En ce qui concerne les applications Web, éloignez-vous des technologies Web du Full Framework (Web Forms, l'ancien MVC, API Web , etc.) et tout ira bien. ASP.NET Core s'améliore continuellement, et le genre d'innovation que nous voyons dans l'espace Blazor est quelque chose.

En outre, C # en tant que langage évolue constamment aussi, et j'ai hâte que novembre soit utilisé. Nouvelles fonctionnalités de C # 9 !

Clôture

Dans cet article, nous avons vu un tas de technologies basées sur ASP.NET Core, à quoi chacune d'elles est destinée et comment elles pourraient être utilisées créer une application.

Si vous débutez avec .NET ou si vous apprenez à coder, les didacticiels de mise en route de Microsoft Docs ( voici un exemple ) sont probablement le meilleur point de départ.

Notes de bas de page [19659389]




Source link