Examen des méthodes de suppression et de détails générés automatiquement

par Rick Anderson

Remarque

Une version mise à jour de ce didacticiel est disponible ici à l’aide de la dernière version de Visual Studio. Le nouveau tutoriel utilise ASP.NET Core MVC, qui fournit de nombreuses améliorations sur ce didacticiel.

Ce didacticiel décrit ASP.NET Core MVC avec des contrôleurs et des vues. Razor Pages est une nouvelle alternative dans ASP.NET Core, un modèle de programmation basé sur des pages qui facilite la création d’une interface utilisateur web plus facile et plus productive. Nous vous recommandons de suivre le didacticiel sur les pages Razor avant la version MVC. Le didacticiel sur les pages Razor :

• est plus facile à suivre ;
• couvre davantage de fonctionnalités ;
• Est l’approche recommandée pour le développement d’applications.

Dans cette partie du tutoriel, vous allez examiner les méthodes générées et Delete générées Details automatiquement.

Examen des méthodes Details et Delete

Ouvrez le Movie contrôleur et examinez la Details méthode.

public ActionResult Details(int? id)
{
    if (id == null)
    {
        return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
    }
    Movie movie = db.Movies.Find(id);
    if (movie == null)
    {
        return HttpNotFound();
    }
    return View(movie);
}

Le moteur de génération automatique MVC qui a créé cette méthode d’action ajoute un commentaire montrant une requête HTTP qui appelle la méthode. Dans ce cas, il s’agit d’une GET requête avec trois segments d’URL, le Movies contrôleur, la Details méthode et une ID valeur.

Le code First facilite la recherche de données à l’aide de la Find méthode. Une fonctionnalité de sécurité importante intégrée à la méthode est que le code vérifie que la Find méthode a trouvé un film avant que le code tente de faire quoi que ce soit avec elle. Par exemple, un pirate informatique pourrait induire des erreurs dans le site en modifiant l’URL créée par les liens, en remplaçant http://localhost:xxxx/Movies/Details/1 par quelque chose comme http://localhost:xxxx/Movies/Details/12345 (ou une autre valeur qui ne représente pas un film réel). Si vous n’avez pas vérifié un film Null, un film Null entraîne une erreur de base de données.

Examinez les méthodes Delete et DeleteConfirmed.

// GET: /Movies/Delete/5
public ActionResult Delete(int? id)
{
    if (id == null)
    {
        return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
    }
    Movie movie = db.Movies.Find(id);
    if (movie == null)
    {
        return HttpNotFound();
    }
    return View(movie);
}

// POST: /Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public ActionResult DeleteConfirmed(int id)
{
    Movie movie = db.Movies.Find(id);
    db.Movies.Remove(movie);
    db.SaveChanges();
    return RedirectToAction("Index");
}

Notez que la méthode HTTP GET Delete ne supprime pas le film spécifié, elle retourne une vue du film dans laquelle vous pouvez envoyer (HttpPost) la suppression. L’exécution d’une opération de suppression en réponse à une requête GET (ou encore l’exécution d’une opération de modification, d’une opération de création ou de toute autre opération qui modifie des données) génère une faille de sécurité.

La méthode HttpPost qui supprime les données est nommée DeleteConfirmed pour donner à la méthode HTTP POST une signature ou un nom unique. Les signatures des deux méthodes sont illustrées ci-dessous :

// GET: /Movies/Delete/5
public ActionResult Delete(int? id)

//
// POST: /Movies/Delete/5
[HttpPost, ActionName("Delete")]
public ActionResult DeleteConfirmed(int id)

Le Common Language Runtime (CLR) nécessite des méthodes surchargées pour avoir une signature à paramètre unique (même nom de méthode, mais liste de paramètres différentes). Toutefois, ici, vous avez besoin de deux méthodes Delete ( une pour GET et une pour POST) qui ont toutes les deux la même signature de paramètre. (Elles doivent toutes les deux accepter un entier unique comme paramètre.)

Pour trier cela, vous pouvez faire quelques choses. Il s’agit de donner des noms différents aux méthodes. C’est ce qu’a fait le mécanisme de génération de modèles automatique dans l’exemple précédent. Toutefois, elle présente un petit problème : ASP.NET mappe des segments d’une URL à des méthodes d’action par nom. Si vous renommez une méthode, il est probable que le routage ne pourra pas trouver cette méthode. La solution consiste à faire ce que vous voyez dans l’exemple, c’est-à-dire à ajouter l’attribut ActionName("Delete") à la méthode DeleteConfirmed. Cela effectue efficacement le mappage pour le système de routage afin qu’une URL incluant /Delete/ pour une requête POST trouve la DeleteConfirmed méthode.

Une autre façon courante d’éviter un problème avec les méthodes qui ont des noms et des signatures identiques consiste à modifier artificiellement la signature de la méthode POST pour inclure un paramètre inutilisé. Par exemple, certains développeurs ajoutent un type de FormCollection paramètre passé à la méthode POST, puis n’utilisent pas simplement le paramètre :

public ActionResult Delete(FormCollection fcNotUsed, int id = 0)
{
    Movie movie = db.Movies.Find(id);
    if (movie == null)
    {
        return HttpNotFound();
    }
    db.Movies.Remove(movie);
    db.SaveChanges();
    return RedirectToAction("Index");
}

Résumé

Vous disposez maintenant d’une application MVC complète ASP.NET qui stocke les données dans une base de données de base de données locale. Vous pouvez créer, lire, mettre à jour, supprimer et rechercher des films.

Étapes suivantes

Une fois que vous avez créé et testé une application web, l’étape suivante consiste à la mettre à la disposition d’autres personnes à utiliser sur Internet. Pour ce faire, vous devez le déployer sur un fournisseur d’hébergement web. Microsoft propose un hébergement web gratuit pour jusqu’à 10 sites web dans un compte d’essai Azure gratuit. Je vous suggère ensuite de suivre mon tutoriel Déployer une application MVC sécurisée ASP.NET avec appartenance, OAuth et SQL Database sur Azure. Un excellent didacticiel est le niveau intermédiaire de Tom Dykstra qui crée un modèle de données Entity Framework pour une application MVC ASP.NET. Stackoverflow et les forums ASP.NET MVC sont un excellent endroit pour poser des questions. Suivez-moi sur Twitter pour obtenir des mises à jour sur mes derniers tutoriels.

Les commentaires sont bienvenus.

— Rick Anderson twitter : @RickAndMSFT
— Scott Hanselman twitter : @shanselman

Précédent