Zpracování požadavků pomocí kontrolerů v ASP.NET Core MVC

  • Článek

Steve Smith a Scott Addie

Kontrolery, akce a výsledky akcí jsou základní součástí toho, jak vývojáři vytvářejí aplikace pomocí ASP.NET Core MVC.

Co je kontroler?

Kontroler slouží k definování a seskupení sady akcí. Akce (nebo metoda akce) je metoda na kontroleru, který zpracovává požadavky. Kontrolery logicky seskupí podobné akce dohromady. Tato agregace akcí umožňuje souhrnně použít společné sady pravidel, jako je směrování, ukládání do mezipaměti a autorizace. Požadavky se mapují na akce prostřednictvím směrování. Kontrolery se aktivují a vyřaďte na každý požadavek.

Podle konvence třídy kontroleru:

  • Nachází se ve složce Řadiče kořenové úrovně projektu.
  • Dědit z Microsoft.AspNetCore.Mvc.Controller.

Kontroler je okamžitě dostupná třída, obvykle veřejná, ve které platí alespoň jedna z následujících podmínek:

  • Název třídy je příponou Controller.
  • Třída dědí z třídy, jejíž název je příponou Controller.
  • Atribut [Controller] se použije na třídu.

Třída kontroleru nesmí mít přidružený [NonController] atribut.

Kontrolery by měly dodržovat zásadu explicitních závislostí. Existuje několik přístupů k implementaci tohoto principu. Pokud více akcí kontroleru vyžaduje stejnou službu, zvažte použití injektáže konstruktoru k vyžádání těchto závislostí. Pokud je služba potřebná pouze jednou metodou akce, zvažte použití injektáže akce k vyžádání závislosti.

V rámci modelu ontroller Model-View-C zodpovídá kontroler za počáteční zpracování požadavku a vytvoření instance modelu. Obecně platí, že obchodní rozhodnutí by se měla provádět v rámci modelu.

Kontroler převezme výsledek zpracování modelu (pokud existuje) a vrátí buď správné zobrazení a jeho přidružená data zobrazení, nebo výsledek volání rozhraní API. Další informace najdete v přehledu ASP.NET Core MVC a začínáme s ASP.NET Core MVC a sadou Visual Studio.

Kontroler je abstrakce na úrovni uživatelského rozhraní. Jeho odpovědností je zajistit, aby data požadavku byla platná a zvolila, které zobrazení (nebo výsledek pro rozhraní API) se má vrátit. V dobře faktorovaných aplikacích nezahrnuje přímý přístup k datům ani obchodní logiku. Místo toho správce deleguje na služby, které tyto povinnosti zpracovávají.

Definování akcí

Veřejné metody v kontroleru s výjimkou těch, které mají [NonAction] atribut, jsou akce. Parametry akcí jsou vázané na data požadavku a ověřují se pomocí vazby modelu. K ověření modelu dochází pro vše, co je vázané na model. Hodnota ModelState.IsValid vlastnosti označuje, zda vazby modelu a ověření proběhlo úspěšně.

Metody akcí by měly obsahovat logiku pro mapování požadavku na obchodní problém. Obchodní obavy by se obvykle měly reprezentovat jako služby, ke kterým kontroler přistupuje prostřednictvím injektáže závislostí. Akce pak namapuje výsledek obchodní akce na stav aplikace.

Akce můžou vrátit cokoli, ale často vrací instanci IActionResult (nebo Task<IActionResult> pro asynchronní metody), která vytváří odpověď. Metoda akce zodpovídá za výběr typu odpovědi. Výsledek akce odpovídá.

Pomocné metody kontroleru

Kontrolery obvykle dědí z Controller, i když to není povinné. Odvozování z Controller poskytuje přístup ke třem kategoriím pomocných metod:

1. Metody, které vedou k prázdnému textu odpovědi

Není zahrnuta žádná Content-Type hlavička odpovědi HTTP, protože tělo odpovědi neobsahuje obsah k popisu.

V této kategorii existují dva typy výsledků: Přesměrování a Stavový kód HTTP.

  • Stavový kód HTTP

    Tento typ vrátí stavový kód HTTP. Několik pomocných metod tohoto typu jsou BadRequest, NotFounda Ok. Například return BadRequest(); při spuštění vytvoří stavový kód 400. Pokud jsou metody, jako BadRequestje , NotFounda Ok jsou přetíženy, již nejsou kvalifikovány jako reakce stavového kódu HTTP, protože probíhá vyjednávání obsahu.

  • Přesměrování

    Tento typ vrátí přesměrování na akci nebo cíl (pomocí Redirect, LocalRedirect, RedirectToAction, nebo RedirectToRoute). Například return RedirectToAction("Complete", new {id = 123}); přesměruje na Completepředání anonymního objektu.

    Typ výsledku přesměrování se liší od typu stavového kódu HTTP, a to především při přidání Location hlavičky odpovědi HTTP.

2. Metody, které mají za následek neprázdný text odpovědi s předdefinovaným typem obsahu

Většina pomocných metod v této kategorii obsahuje ContentType vlastnost, která umožňuje nastavit hlavičku Content-Type odpovědi pro popis textu odpovědi.

V této kategorii existují dva typy výsledků: Zobrazit a Formátovaná odpověď.

  • Zobrazení

    Tento typ vrátí zobrazení, které používá model k vykreslení HTML. Například return View(customer); předá model do zobrazení pro datovou vazbu.

  • Formátovaná odpověď

    Tento typ vrátí JSformát ON nebo podobný formát výměny dat, který představuje objekt určitým způsobem. Například return Json(customer); serializuje zadaný objekt do JSformátu ON.

    Mezi další běžné metody tohoto typu patří File a PhysicalFile. Například return PhysicalFile(customerFilePath, "text/xml"); vrátí PhysicalFileResult.

3. Metody, které mají za následek neprázdný text odpovědi formátovaný v typu obsahu vyjednaný s klientem

Tato kategorie se lépe označuje jako vyjednávání obsahu. Vyjednávání obsahu se použije vždy, když akce vrátí ObjectResult typ nebo něco jiného než implementaci IActionResult . Akce, která vrací neimigresiIActionResult (například object) vrátí také formátovanou odpověď.

Mezi pomocné metody tohoto typu patří BadRequest, CreatedAtRoutea Ok. Mezi příklady těchto metod patří return BadRequest(modelState);, return CreatedAtRoute("routename", values, newobject);a return Ok(value);, v uvedeném pořadí. Všimněte si, že BadRequestOk vyjednávání obsahu se provádí pouze při předání hodnoty, aniž by byla předána hodnota, místo toho slouží jako typy výsledků stavového kódu HTTP. Metoda CreatedAtRoute na druhé straně vždy provádí vyjednávání obsahu, protože jeho přetížení všechny vyžadují předání hodnoty.

Průřezové otázky

Aplikace obvykle sdílejí části pracovního postupu. Mezi příklady patří aplikace, která vyžaduje ověření pro přístup k nákupnímu košíku, nebo aplikaci, která ukládá data do mezipaměti na některých stránkách. K provedení logiky před nebo po metodě akce použijte filtr. Použití filtrů u průřezových aspektů může snížit duplicitu.

Většina atributů filtru, například [Authorize], lze použít na úrovni kontroleru nebo akce v závislosti na požadované úrovni členitosti.

Zpracování chyb a ukládání odpovědí do mezipaměti jsou často nejčastějšími aspekty:

Řadu problémů s křížovým dělením je možné zpracovat pomocí filtrů nebo vlastního middlewaru.