Vyer i ASP.NET Core MVC

Av Steve Smith och Dave Brock

Det här dokumentet förklarar vyer som används i ASP.NET Core MVC-program. Information om Razor sidor Razor finns i Sidarkitektur och begrepp i ASP.NET Core.

I MVC-mönstret (Model-View-Controller) hanterar vyn appens datapresentation och användarinteraktion. En vy är en HTML-mall med inbäddad Razor markering. Razor markup är kod som interagerar med HTML-kod för att skapa en webbsida som skickas till klienten.

I ASP.NET Core MVC är .cshtml vyer filer som använder programmeringsspråket C# i Razor markering. Vanligtvis grupperas visningsfiler i mappar med namnet för var och en av appens kontrollanter. Mapparna lagras i en Views mapp i appens rot:

Kontrollanten Home representeras av en Home mapp i Views mappen. Mappen Home innehåller vyerna för webbsidorna About, Contactoch Index (startsidan). När en användare begär någon av dessa tre webbsidor avgör kontrollantåtgärder i kontrollanten Home vilken av de tre vyerna som används för att skapa och returnera en webbsida till användaren.

Använd layouter för att tillhandahålla konsekventa webbplatsavsnitt och minska kodrepetitionen. Layouter innehåller ofta sidhuvud-, navigerings- och menyelementen och sidfoten. Sidhuvud och sidfot innehåller vanligtvis pannplåtsmarkering för många metadataelement och länkar till skript- och formattillgångar. Layouter hjälper dig att undvika den här pannplåtsmarkeringen i dina vyer.

Partiella vyer minskar koddupliceringen genom att hantera återanvändbara delar av vyer. En partiell vy är till exempel användbar för en författarbiografi på en bloggwebbplats som visas i flera vyer. En författarbiografi är vanligt visningsinnehåll och kräver inte att kod körs för att skapa innehållet på webbsidan. Endast redigeringsbiografiinnehåll är tillgängligt för vyn efter modellbindning, så det är idealiskt att använda en partiell vy för den här typen av innehåll.

Visa komponenter liknar partiella vyer eftersom de gör att du kan minska repetitiv kod, men de är lämpliga för att visa innehåll som kräver att kod körs på servern för att återge webbsidan. Visa komponenter är användbara när det renderade innehållet kräver databasinteraktion, till exempel för en kundvagn för en webbplats. Visningskomponenter är inte begränsade till modellbindning för att kunna generera utdata från webbsidan.

Fördelar med att använda vyer

Vyer hjälper till att upprätta separation av problem i en MVC-app genom att separera användargränssnittsmarkeringen från andra delar av appen. Följande SoC-design gör din app modulär, vilket ger flera fördelar:

• Appen är enklare att underhålla eftersom den är bättre organiserad. Vyer grupperas vanligtvis efter appfunktion. Det gör det enklare att hitta relaterade vyer när du arbetar med en funktion.
• Delarna i appen är löst kopplade. Du kan skapa och uppdatera appens vyer separat från komponenterna affärslogik och dataåtkomst. Du kan ändra vyerna för appen utan att nödvändigtvis behöva uppdatera andra delar av appen.
• Det är enklare att testa användargränssnittsdelarna i appen eftersom vyerna är separata enheter.
• På grund av bättre organisation är det mindre troligt att du oavsiktligt upprepar delar av användargränssnittet.

Skapa en vy

Vyer som är specifika för en kontrollant skapas i Views/[ControllerName] mappen. Vyer som delas mellan kontrollanter placeras i Views/Shared mappen. Om du vill skapa en vy lägger du till en ny fil och ger den samma namn som dess associerade kontrollantåtgärd med filnamnstillägget .cshtml . Skapa en fil i mappen för att skapa en vy som motsvarar About åtgärden i kontrollanten About.cshtmlHomeViews/Home:

@{
    ViewData["Title"] = "About";
}
<h2>@ViewData["Title"].</h2>
<h3>@ViewData["Message"]</h3>

<p>Use this area to provide additional information.</p>

Razor markup börjar med symbolen @ . Kör C#-instruktioner genom att placera C#-kod i Razor kodblock som har konfigurerats av klammerparenteser ({ ... }). Se till exempel tilldelningen av "Om" till ViewData["Title"] ovan. Du kan visa värden i HTML genom att bara referera till värdet med symbolen @ . Se innehållet i elementen <h2> och <h3> ovan.

Visningsinnehållet som visas ovan är bara en del av hela webbsidan som återges till användaren. Resten av sidans layout och andra vanliga aspekter av vyn anges i andra vyfiler. Mer information finns i avsnittet Layout.

Så här anger kontrollanter vyer

Vyer returneras vanligtvis från åtgärder som en ViewResult, som är en typ av ActionResult. Din åtgärdsmetod kan skapa och returnera en ViewResult direkt, men det är inte vanligt. Eftersom de flesta kontrollanter ärver från Controlleranvänder View du bara hjälpmetoden för att returnera ViewResult:

HomeController.cs:

public IActionResult About()
{
    ViewData["Message"] = "Your application description page.";

    return View();
}

När den här åtgärden returneras About.cshtml återges vyn som visas i det sista avsnittet som följande webbsida:

Hjälpmetoden View har flera överlagringar. Du kan också ange:

• En explicit vy som ska returneras:

  return View("Orders");
  

• En modell som ska skickas till vyn:

  return View(Orders);
  

• Både en vy och en modell:

  return View("Orders", Orders);
  

Visa identifiering

När en åtgärd returnerar en vy sker en process som kallas visningsidentifiering . Den här processen avgör vilken vyfil som används baserat på visningsnamnet.

Standardbeteendet för View metoden (return View();) är att returnera en vy med samma namn som den åtgärdsmetod som den anropas från. Till exempel AboutActionResult används kontrollantens metodnamn för att söka efter en vyfil med namnet About.cshtml. Först söker körningen Views/[ControllerName] i mappen för vyn. Om den inte hittar någon matchande vy där söker den i Shared mappen efter vyn.

Det spelar ingen roll om du implicit returnerar ViewResult med return View(); eller uttryckligen skickar visningsnamnet till View metoden med return View("<ViewName>");. I båda fallen visar du identifieringssökningar efter en matchande vyfil i den här ordningen:

1. Views/\[ControllerName]/\[ViewName].cshtml
2. Views/Shared/\[ViewName].cshtml

En sökväg till vyfilen kan anges i stället för ett visningsnamn. Om du använder en absolut sökväg som börjar vid approten (om du vill börja med "/" eller "~/"), .cshtml måste tillägget anges:

return View("Views/Home/About.cshtml");

Du kan också använda en relativ sökväg för att ange vyer i olika kataloger utan .cshtml tillägget. HomeControllerI kan du returnera Index vyn för dina Manage vyer med en relativ sökväg:

return View("../Manage/Index");

På samma sätt kan du ange den aktuella kontrollantspecifika katalogen med prefixet "./":

return View("./About");

Partiella vyer och vykomponenter använder liknande (men inte identiska) identifieringsmekanismer.

Du kan anpassa standardkonventionen för hur vyer finns i appen med hjälp av en anpassad IViewLocationExpander.

Visningsidentifiering förlitar sig på att söka efter visningsfiler efter filnamn. Om det underliggande filsystemet är skiftlägeskänsligt är visningsnamn förmodligen skiftlägeskänsliga. För kompatibilitet mellan operativsystem matchar du skiftläget mellan kontrollant- och åtgärdsnamn och associerade vymappar och filnamn. Om du får ett fel om att en vyfil inte kan hittas när du arbetar med ett skiftlägeskänsligt filsystem kontrollerar du att höljet matchar mellan den begärda vyfilen och det faktiska visningsfilens namn.

Följ bästa praxis för att organisera filstrukturen för dina vyer för att återspegla relationerna mellan kontrollanter, åtgärder och vyer för underhåll och tydlighet.

Skicka data till vyer

Skicka data till vyer med hjälp av flera metoder:

• Starkt inskrivna data: viewmodel
• Svagt skrivna data
  • ViewData (ViewDataAttribute)
  • ViewBag

Starkt typerade data (viewmodel)

Den mest robusta metoden är att ange en modelltyp i vyn. Den här modellen kallas ofta för en viewmodel. Du skickar en instans av viewmodel-typen till vyn från åtgärden.

Genom att använda en viewmodel för att skicka data till en vy kan vyn dra nytta av stark typkontroll. Stark typinmatning (eller starkt skrivet) innebär att varje variabel och konstant har en explicit definierad typ (till exempel string, inteller DateTime). Giltigheten för de typer som används i en vy kontrolleras vid kompileringstillfället.

Visual Studio och Visual Studio Code listar starkt inskrivna klassmedlemmar med hjälp av en funktion som heter IntelliSense. När du vill se egenskaperna för en viewmodel skriver du variabelnamnet för viewmodel följt av en punkt (.). Detta hjälper dig att skriva kod snabbare med färre fel.

Ange en modell med hjälp av @model direktivet. Använd modellen med @Model:

@model WebApplication1.ViewModels.Address

<h2>Contact</h2>
<address>
    @Model.Street<br>
    @Model.City, @Model.State @Model.PostalCode<br>
    <abbr title="Phone">P:</abbr> 425.555.0100
</address>

För att tillhandahålla modellen till vyn skickar kontrollanten den som en parameter:

public IActionResult Contact()
{
    ViewData["Message"] = "Your contact page.";

    var viewModel = new Address()
    {
        Name = "Microsoft",
        Street = "One Microsoft Way",
        City = "Redmond",
        State = "WA",
        PostalCode = "98052-6399"
    };

    return View(viewModel);
}

Det finns inga begränsningar för de modelltyper som du kan ange för en vy. Vi rekommenderar att du använder POCO-vymodels (Plain Old CLR Object) med lite eller inget beteende (metoder) definierat. Vanligtvis lagras viewmodel-klasser antingen i Models mappen eller i en separat ViewModels mapp i appens rot. Den Address vymodell som används i exemplet ovan är en POCO-vymodell som lagras i en fil med namnet Address.cs:

namespace WebApplication1.ViewModels
{
    public class Address
    {
        public string Name { get; set; }
        public string Street { get; set; }
        public string City { get; set; }
        public string State { get; set; }
        public string PostalCode { get; set; }
    }
}

Ingenting hindrar dig från att använda samma klasser för både dina viewmodel-typer och dina typer av affärsmodeller. Om du använder separata modeller kan dina vyer dock variera oberoende av affärslogik och dataåtkomst i din app. Separation av modeller och visningsmodeller ger också säkerhetsfördelar när modeller använder modellbindning och validering för data som skickas till appen av användaren.

Svagt inskrivna data (ViewData, [ViewData] attribut och ViewBag)

ViewBag är inte tillgängligt som standard för användning i Razor SidklasserPageModel.

Förutom starkt skrivna vyer har vyer åtkomst till en svagt typad (kallas även löst typad) datainsamling. Till skillnad från starka typer innebär svaga typer (eller lösa typer) att du inte uttryckligen deklarerar vilken typ av data du använder. Du kan använda samlingen med svagt inskrivna data för att skicka små mängder data till och från kontrollanter och vyer.

Den här samlingen kan refereras via antingen ViewData egenskaperna eller ViewBag på kontrollanter och vyer. Egenskapen ViewData är en ordlista med svagt inskrivna objekt. Egenskapen ViewBag är en omslutning som ViewData ger dynamiska egenskaper för den underliggande ViewData samlingen. Obs! Viktiga sökningar är skiftlägeskänsliga för både ViewData och ViewBag.

ViewData och ViewBag löses dynamiskt vid körning. Eftersom de inte erbjuder kompileringstidstypkontroll är båda vanligtvis mer felbenägna än att använda en viewmodel. Av den anledningen föredrar vissa utvecklare att minimalt eller aldrig använda ViewData och ViewBag.

ViewData

ViewData är ett ViewDataDictionary objekt som nås via string nycklar. Strängdata kan lagras och användas direkt utan behov av en gjutning, men du måste omvandla andra ViewData objektvärden till specifika typer när du extraherar dem. Du kan använda ViewData för att skicka data från kontrollanter till vyer och i vyer, inklusive partiella vyer och layouter.

Följande är ett exempel som anger värden för en hälsning och en adress som använder ViewData i en åtgärd:

public IActionResult SomeAction()
{
    ViewData["Greeting"] = "Hello";
    ViewData["Address"]  = new Address()
    {
        Name = "Steve",
        Street = "123 Main St",
        City = "Hudson",
        State = "OH",
        PostalCode = "44236"
    };

    return View();
}

Arbeta med data i en vy:

@{
    // Since Address isn't a string, it requires a cast.
    var address = ViewData["Address"] as Address;
}

@ViewData["Greeting"] World!

<address>
    @address.Name<br>
    @address.Street<br>
    @address.City, @address.State @address.PostalCode
</address>

[ViewData] attribut

En annan metod som använder ViewDataDictionary är ViewDataAttribute. Egenskaper på kontrollanter eller Razor sidmodeller som har markerats med [ViewData] attributet har sina värden lagrade och inlästa från ordlistan.

I följande exempel innehåller kontrollanten Home en Title egenskap som är markerad med [ViewData]. Metoden About anger rubriken för vyn Om:

public class HomeController : Controller
{
    [ViewData]
    public string Title { get; set; }

    public IActionResult About()
    {
        Title = "About Us";
        ViewData["Message"] = "Your application description page.";

        return View();
    }
}

I layouten läss rubriken från ordlistan ViewData:

<!DOCTYPE html>
<html lang="en">
<head>
    <title>@ViewData["Title"] - WebApplication</title>
    ...

ViewBag

ViewBag är inte tillgängligt som standard för användning i Razor SidklasserPageModel.

ViewBag är ett Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.DynamicViewData objekt som ger dynamisk åtkomst till de objekt som lagras i ViewData. ViewBag kan vara bekvämare att arbeta med, eftersom det inte kräver gjutning. I följande exempel visas hur du använder ViewBag med samma resultat som ovan ViewData :

public IActionResult SomeAction()
{
    ViewBag.Greeting = "Hello";
    ViewBag.Address  = new Address()
    {
        Name = "Steve",
        Street = "123 Main St",
        City = "Hudson",
        State = "OH",
        PostalCode = "44236"
    };

    return View();
}

@ViewBag.Greeting World!

<address>
    @ViewBag.Address.Name<br>
    @ViewBag.Address.Street<br>
    @ViewBag.Address.City, @ViewBag.Address.State @ViewBag.Address.PostalCode
</address>

Använda ViewData och ViewBag samtidigt

ViewBag är inte tillgängligt som standard för användning i Razor SidklasserPageModel.

Eftersom ViewData och ViewBag refererar till samma underliggande ViewData samling kan du använda både ViewData och ViewBag och blanda och matcha dem när du läser och skriver värden.

Ange rubriken med hjälp av ViewBag och beskrivningen överst ViewData i en About.cshtml vy:

@{
    Layout = "/Views/Shared/_Layout.cshtml";
    ViewBag.Title = "About Contoso";
    ViewData["Description"] = "Let us tell you about Contoso's philosophy and mission.";
}

Läs egenskaperna men ångra användningen av ViewData och ViewBag. _Layout.cshtml I filen hämtar du rubriken med hjälp av ViewData och hämtar beskrivningen med hjälp av ViewBag:

<!DOCTYPE html>
<html lang="en">
<head>
    <title>@ViewData["Title"]</title>
    <meta name="description" content="@ViewBag.Description">
    ...

Kom ihåg att strängar inte kräver någon gjutning för ViewData. Du kan använda @ViewData["Title"] utan gjutning.

Att använda både ViewData och ViewBag samtidigt fungerar, liksom blandning och matchande läsning och skrivning av egenskaperna. Följande markering återges:

<!DOCTYPE html>
<html lang="en">
<head>
    <title>About Contoso</title>
    <meta name="description" content="Let us tell you about Contoso's philosophy and mission.">
    ...

Sammanfattning av skillnaderna mellan ViewData och ViewBag

ViewBag är inte tillgängligt som standard för användning i Razor SidklasserPageModel.

• ViewData
  • Härleds från ViewDataDictionary, så den har ordlisteegenskaper som kan vara användbara, till exempel ContainsKey, Add, Removeoch Clear.
  • Nycklar i ordlistan är strängar, så blanksteg tillåts. Exempel: ViewData["Some Key With Whitespace"]
  • Alla andra typer än en string måste gjutas i vyn för att använda ViewData.
• ViewBag
  • Härleds från Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.DynamicViewData, så det gör det möjligt att skapa dynamiska egenskaper med hjälp av punkt notation (@ViewBag.SomeKey = <value or object>), och ingen gjutning krävs. Syntaxen ViewBag för gör det snabbare att lägga till i kontrollanter och vyer.
  • Enklare att söka efter null-värden. Exempel: @ViewBag.Person?.Name

När du ska använda ViewData eller ViewBag

Både ViewData och ViewBag är lika giltiga metoder för att skicka små mängder data mellan kontrollanter och vyer. Valet av vilken som ska användas baseras på inställningar. Du kan blanda och matcha ViewData och ViewBag objekt, men koden är lättare att läsa och underhålla med en metod som används konsekvent. Båda metoderna löses dynamiskt vid körning och kan därför orsaka körningsfel. Vissa utvecklingsteam undviker dem.

Dynamiska vyer

Vyer som inte deklarerar en modelltyp med men @model som har en modellinstans skickad till dem (till exempel return View(Address);) kan referera till instansens egenskaper dynamiskt:

<address>
    @Model.Street<br>
    @Model.City, @Model.State @Model.PostalCode<br>
    <abbr title="Phone">P:</abbr> 425.555.0100
</address>

Den här funktionen erbjuder flexibilitet men erbjuder inte kompileringsskydd eller IntelliSense. Om egenskapen inte finns misslyckas genereringen av webbsidan vid körning.

Fler visningsfunktioner

Tagghjälpare gör det enkelt att lägga till beteende på serversidan i befintliga HTML-taggar. Om du använder Tag Helpers undviker du behovet av att skriva anpassad kod eller hjälp i dina vyer. Tagghjälpare används som attribut för HTML-element och ignoreras av redigerare som inte kan bearbeta dem. På så sätt kan du redigera och återge visningspålägg i en mängd olika verktyg.

Du kan skapa anpassad HTML-kod med många inbyggda HTML-hjälpare. Mer komplex logik för användargränssnittet kan hanteras av Visa komponenter. Visa komponenter ger samma SoC som kontrollanter och vyer erbjuder. De kan eliminera behovet av åtgärder och vyer som hanterar data som används av vanliga användargränssnittselement.

Liksom många andra aspekter av ASP.NET Core stöder vyer beroendeinmatning, vilket gör att tjänster kan matas in i vyer.

h1 {
    color: red;
}

<link rel="stylesheet" href="~/{APP ASSEMBLY}.styles.css" />

<link rel="stylesheet" href="WebApp.styles.css" />

/* /Pages/Index.cshtml.rz.scp.css */
h1[b-3xxtam6d07] {
    color: red;
}

<h1 b-3xxtam6d07>

<ItemGroup>
  <None Update="{Pages|Views}/Index.cshtml.css" CssScope="custom-scope-identifier" />
</ItemGroup>

<ItemGroup>
  <None Update="{Pages|Views}/BaseView.cshtml.css" CssScope="custom-scope-identifier" />
  <None Update="{Pages|Views}/DerivedView.cshtml.css" CssScope="custom-scope-identifier" />
</ItemGroup>

<ItemGroup>
  <None Update="{Pages|Views}/*.cshtml.css" CssScope="custom-scope-identifier" />
</ItemGroup>

<PropertyGroup>
  <StaticWebAssetBasePath>_content/$(PackageId)</StaticWebAssetBasePath>
</PropertyGroup>

<PropertyGroup>
  <DisableScopedCssBundling>true</DisableScopedCssBundling>
</PropertyGroup>

<link href="_content/ClassLib/ClassLib.bundle.scp.css" rel="stylesheet">