Hvordan lokalisere og globalisere en webapplikation med ASP.NET Core

I kapitel 7, "Håndtering af datoer, tid og internationalisering", lærte du om arbejdet med datoer, tid, tidszoner og hvordan du globaliserer og lokaliserer en .NET-kodebase. I denne sektion vil vi fokusere på, hvordan du kan lokalisere en webside, der bruger ASP.NET Core, både med henblik på strenglokalisering og globalisering af data som datoer og valutaer.

Når du lokaliserer en webapplikation, handler det ikke kun om at oversætte tekstindhold, men også om at tilpasse den kulturelle kontekst for at sikre, at brugeroplevelsen føles naturlig og korrekt for forskellige geografiske områder og sproggrupper. Du kan for eksempel bruge IStringLocalizer til at lokalisere strengværdier og IHtmlLocalizer til at lokalisere HTML-værdier. Det er dog vigtigt at bemærke, at HTML-struktur normalt bør være den samme på tværs af lokaliteter, da det er indholdet, der skal tilpasses. For visninger kan du bruge IViewLocalizer.

Oprettelse af ressourcefiler

1. I dit ASP.NET Core-projekt, opret en ny mappe kaldet Resources. Dette er standardmappen, som lokaliseringsservices ser i efter *.resx-resursefiler.

2. I Resources-mappen, opret en ny undermappe kaldet Views.

3. I Views-mappen, opret en ny undermappe kaldet Home.

Nu er vi klar til at oprette ressourcefilerne.

I Visual Studio 2022

1. I Home-mappen, opret en ny ressourcefil kaldet Index.en-US.resx.

2. Brug ressourcefilredigeringsværktøjet til at definere navne og værdier for de forskellige lokaliserede etiketter.

3. Kopiér og indsæt filen og omdøb den til Index.en-GB.resx og ændr værdierne, hvor det er nødvendigt, for at skelne mellem amerikansk og britisk engelsk.

4. Fortsæt på samme måde for at oprette franske versioner af ressourcefilerne: Index.fr-FR.resx og Index.fr.resx, og tilpas værdierne til fransk sprog og kultur.

I Visual Studio Code

1. I Home-mappen, opret en ny fil kaldet Index.en-US.resx.

2. Rediger indholdet af denne fil, så den indeholder de engelske værdier, som f.eks. virksomhedens navn, land, antal varer, bestillingsdato osv.

3. Kopiér filen og omdøb den til Index.en-GB.resx, og ændr værdierne til britisk engelsk, som f.eks. ændre USA til Storbritannien.

4. Opret franske versioner af filerne som beskrevet ovenfor.

Lokalisering af Razor-visninger

Når ressourcefilerne er oprettet, kan vi begynde at lokalisere Razor-visningerne. Dette kræver, at vi importerer et specifikt navnerum for lokaliseringsarbejde og injicerer IViewLocalizer-servicen i vores visning.

I Views/Home/Index.cshtml gør vi følgende:

1. Importer navnerummet for lokaliseringsarbejde:

   csharp
   Copy code
   @using Microsoft.AspNetCore.Mvc.Localization
   @inject IViewLocalizer Localizer
   

2. Ændr visningens model og brug lokaliseringsnøglerne til at vise de lokaliserede værdier:

   csharp
   Copy code
   @{ ViewData["Title"] = Localizer["Orders"]; }
   
   

Konfiguration af lokaliseringsservices

For at gøre det muligt at håndtere forskellige lokaliteter og kulturer, skal vi konfigurere ASP.NET Core til at understøtte de ønskede sprog- og kulturopsætninger. Dette gøres i Program.cs-filen:

1. Før opkaldet til AddControllersWithViews, skal vi tilføje konfigurationen for lokaliseringsservices og angive stien til ressourcemapperne:

   csharp
   Copy code
   builder.Services.AddLocalization(options => options.ResourcesPath = "Resources");
   builder.Services.AddControllersWithViews().AddViewLocalization();
   

2. Efter opkaldet til Build-metoden i Program.cs, deklarer de kulturer, du vil understøtte. For eksempel kan vi understøtte amerikansk engelsk, britisk engelsk, neutral fransk og fransk i Frankrig:

   csharp
   Copy code
   string[] cultures = new[] { "en-US", "en-GB", "fr", "fr-FR" };
   
   RequestLocalizationOptions localizationOptions = new();
   localizationOptions.SetDefaultCulture(cultures[0])
      .AddSupportedCultures(cultures)
      .AddSupportedUICultures(cultures);
   app.UseRequestLocalization(localizationOptions);
   

Med denne konfiguration vil webapplikationen kunne vise data i den ønskede kultur, som f.eks. datoformater og valuta, samtidig med at brugergrænsefladen lokaliseres.

Implementering af browserens sprogindstillinger

Når du har konfigureret din webapplikation til at understøtte flere kulturer, kan brugerne vælge deres foretrukne kultur. Dette kan gøres ved at tilføje en parameter til URL’en, sende en cookie eller angive en HTTP-header, som browseren sender med anmodningen.

I Chrome kan du for eksempel navigere til Indstillinger og søge efter sprogindstillinger. Hvis du bruger en lokaliseret version af Chrome, vil du muligvis skulle søge på dit eget sprog, såsom "språk" på svensk eller "idioma" på spansk.

Ved at konfigurere ASP.NET Core til at håndtere sådanne forespørgsler, kan du sikre, at applikationen vises korrekt i henhold til brugerens sprogpræferencer og den relevante kultur.

Det er vigtigt at forstå, at lokaliseringsarbejde ikke kun handler om oversættelse. Det indebærer at tage højde for kulturelle forskelle i format, skrift, og hvordan data som datoer, valutaer og adresser vises. Udover at oversætte tekst, skal du sikre dig, at din applikation fungerer korrekt i forskellige kulturer ved at tilpasse disse formater.

Hvordan måle ydeevne og håndtere samtidige opgaver i .NET?

I et simpelt eksempel som at sammenligne string concatenation og brug af StringBuilder, kan vi få indsigt i, hvordan små optimeringer kan have stor betydning for ydeevnen i store applikationer. Når vi kører benchmark-tests, vil resultaterne vise, hvordan en specifik metode præsterer sammenlignet med en anden.

For eksempel, når vi tester string-konkatenering og StringBuilder i et .NET 7.0 miljø, får vi resultater som:

• String-konkatenering tager et gennemsnit på 412.990 nanosekunder.

• StringBuilder tager et gennemsnit på 275.082 nanosekunder.

En vigtig bemærkning ved sådanne tests er håndteringen af outliers. Hvis din test viser usædvanlige eller ekstreme resultater, er det vigtigt at bemærke, hvordan disse outliers kan påvirke gennemsnittet og analysen. For eksempel, i ovenstående tests, blev der fjernet syv outliers for string-konkatenering og kun to for StringBuilder. Dette indikerer, at string-konkatenering er mere følsom overfor ydre faktorer, som kan forårsage uforudsigelige resultater.

Når man arbejder med samtidige opgaver, er det også nødvendigt at forstå, hvordan man kan køre flere opgaver parallelt for at forbedre ydeevnen. Dette kan gøres effektivt ved at anvende asynkrone metoder i .NET. I et eksempel, hvor tre metoder skal køres samtidig (hvor den første tager 3 sekunder, den anden 2 sekunder, og den sidste 1 sekund), kan asynkrone opgaver reducere den samlede ventetid, da alle opgaverne kan køre samtidigt, i stedet for at vente på, at én opgave afsluttes før den næste starter.

Før man begynder at køre opgaver asynkront, kan man dog teste ydeevnen synkront. For at gøre dette, kan man lave et simpelt program, hvor man simulerer tre metoder, der hver tager forskellig tid at fuldføre. Den synkrone metode vil se ud som følger:

1. Metode A kører og tager 3 sekunder.

2. Metode B kører og tager 2 sekunder.

3. Metode C kører og tager 1 sekund.

Den synkrone kørsel betyder, at programmet skal vente på, at Metode A afsluttes, før Metode B begynder, og derefter vente på Metode B, før Metode C kan startes. Den samlede tid for at køre alle tre opgaver vil være summen af de individuelle tider, hvilket resulterer i 6 sekunder.

Et godt eksempel på dette kunne være at anvende Thread.Sleep() til at simulere, at metoderne tager tid, og derefter bruge asynkrone opgaver til at køre disse metoder samtidigt.

I praksis er det nødvendigt at overveje flere faktorer, når man arbejder med asynkron programmering. For eksempel skal man være opmærksom på, hvordan tråde håndteres i .NET, samt hvilke metoder og teknikker der er mest effektive for ens specifikke applikation. Asynkrone opgaver kan føre til betydelige forbedringer i ydeevnen, men det er vigtigt at forstå, hvornår og hvordan man skal anvende dem korrekt for at undgå fejl og ineffektivitet i koden.

Når vi sammenligner synkrone og asynkrone metoder, er det tydeligt, at asynkrone opgaver kan give en markant forbedring i ydeevnen, især når det drejer sig om at køre mange uafhængige opgaver samtidig. Det er dog vigtigt at forstå, at ikke alle opgaver nødvendigvis vil drage fordel af asynkron kørsel, og at der kan være scenarier, hvor synkrone metoder er tilstrækkelige.

Det er også vigtigt at bemærke, at den samlede ydeevne ikke kun afhænger af, hvordan opgaverne er organiseret, men også af hardware-konfigurationen, hvilket er grunden til, at det altid er en god idé at køre flere tests og målinger under forskellige betingelser for at få et klart billede af, hvordan ens applikation præsterer.

Hvordan Opbygger Man Opkald og Synkronisering af Opgaver i C#?

En grundlæggende teknik i C# til at starte opgaver er at bruge Task-klassen. I eksemplet herunder starter vi en opgave, der kører en anden opgave. Dette er nyttigt, når du har behov for at håndtere en proces, der skal køre parallelt med andre opgaver:

csharp
Copy code
static void OuterMethod() 
{
    TaskTitle("Outer method starting...");
    Task innerTask = Task.Factory.StartNew(InnerMethod);
    TaskTitle("Outer method finished.");
}
static void InnerMethod() 
{
    TaskTitle("Inner method starting...");
    Thread.Sleep(2000);
    TaskTitle("Inner method finished.");
}

For at sikre, at den indre opgave afsluttes før den ydre, skal vi knytte den til den ydre opgave ved hjælp af en speciel option:

csharp
Copy code
Task innerTask = Task.Factory.StartNew(InnerMethod, TaskCreationOptions.AttachedToParent);

Med denne ændring venter den ydre opgave på, at den indre opgave afsluttes, før applikationen stopper:

csharp
Copy code
Outer method starting...

Inner method starting...
Outer method finished.
Inner method finished.
Console app is stopping.

Når du arbejder med opgaver, kan der opstå situationer, hvor du har en metode, der skal være asynkron, men ikke nødvendigvis returnerer en opgave. I sådanne tilfælde kan du bruge Task.FromResult, Task.FromException eller Task.FromCanceled metoderne til at oprette en opgave, der allerede er afsluttet. Dette kan være nyttigt, når du implementerer en grænseflade, der kræver asynkrone metoder, men den underliggende metode er synkron.

Her er et eksempel, hvor du bruger Task.FromResult til at oprette en opgave, der returnerer et resultat:

csharp
Copy code
public interface IValidation 
{

    Task<bool> IsValidXmlTagAsync(string input);

}
public static class StringExtensions : IValidation 
{
    public static Task<bool> IsValidXmlTagAsync(this string input) 
    {
        if (input == null) 
        {

            return Task.FromException<bool>(new ArgumentNullException($"Missing {nameof(input)} parameter"));

        }
        if (input.Length == 0) 
        {
            return Task.FromException<bool>(new ArgumentException($"{nameof(input)} parameter is empty."));
        }
        return Task.FromResult(Regex.IsMatch(input, @"^<([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+\/>)$"));
    }
}

Ovenstående metode simulerer et asynkront kald, men det er synkront, da det ikke nødvendigvis kræver nogen virkelig asynkron operation, men det giver dig mulighed for at arbejde med en grænseflade, der forventer en opgave.

Når man arbejder med samtidige opgaver, er en vigtig faktor at sikre trådsikker adgang til delte ressourcer. Når flere tråde forsøger at få adgang til en delt ressource, kan der opstå race conditions, hvor den ene tråd overskriver en andens ændringer. For at undgå dette skal du sikre, at kun én tråd har adgang til ressourcen ad gangen. En enkel måde at implementere trådsikker adgang er ved hjælp af en flagmekanisme, der fungerer som et trafiklys.

I C# kan du bruge Monitor eller Interlocked til at sikre synkronisering. Monitor giver dig mulighed for at kontrollere, om en tråd skal få adgang til en delt ressource, mens Interlocked giver dig mulighed for at manipulere simple numeriske typer på CPU-niveau.

Et praktisk eksempel på synkronisering af opgaver og adgang til delte ressourcer kan se sådan ud:

csharp
Copy code
static class SharedObjects

{
    public static string? Message; // en delt ressource
}
static void MethodA()
{
    for (int i = 0; i < 5; i++)
    {
        Thread.Sleep(Random.Shared.Next(2000));
        SharedObjects.Message += "A";
        Write(".");
    }
}
static void MethodB()
{
    for (int i = 0; i < 5; i++)
    {
        Thread.Sleep(Random.Shared.Next(2000));
        SharedObjects.Message += "B";
        Write(".");
    }
}

Når du kører opgaverne parallelt, kan du opleve et resultat, der ser ud som følger:

csharp
Copy code
Please wait for the tasks to complete.

.......... 
Results: BABABAABBA.
5,753 elapsed milliseconds.

Det er vigtigt at forstå, at når du arbejder med samtidige opgaver, er der mange nuancer, der kræver opmærksomhed. Udover den synkronisering, som er blevet præsenteret her, bør du overveje, hvordan fejl håndteres i asynkrone metoder og hvordan du kan bruge undtagelseshåndtering til at sikre, at applikationen ikke går ned, hvis noget går galt under kørsel. Desuden er det også væsentligt at forstå forskellen mellem "fire and forget" opgaver og opgaver, der skal vente på afslutning, da begge metoder kræver forskellig håndtering for at undgå utilsigtet adfærd eller fejl.

Hvordan forbedrer async og await multitasking på serversiden, og hvilke almindelige typer understøtter dette?

Brugen af async og await i serversideprogrammering har til formål at øge effektiviteten ved at frigøre dyrebare I/O-tråde, så de ikke sidder fast i ventetilstand på langsigtede opgaver. I stedet oprettes billigere arbejdstråde, der venter på, at disse opgaver bliver færdige, hvilket øger serverens evne til at håndtere flere klientanmodninger samtidig. Denne form for multitasking forbedrer skalerbarheden af webapplikationer og -tjenester betragteligt, da flere brugere kan serviceres parallelt uden at blokere kritiske ressourcer.

Mange almindelige typer i .NET-økosystemet understøtter asynkrone metoder, der kan anvendes med await. Eksempler på sådanne typer omfatter DbContext og DbSet, der har metoder som AddAsync, FindAsync og SaveChangesAsync, HttpClient med GetAsync, PostAsync og SendAsync, samt StreamReader og StreamWriter, som har henholdsvis ReadAsync og WriteAsync metoder. Når man ser en metode med Async-suffikset, bør man undersøge, om den returnerer en Task eller Task<T>, hvilket indikerer, at den kan anvendes asynkront sammen med await, og metoden der kalder den skal være markeret med async.

Siden introduktionen af async og await i C# 5 har sproget udviklet sig, så det nu også er muligt at anvende await i catch-blokke. Det muliggør bedre fejlhåndtering i asynkrone programmer ved at lade kode vente på afslutningen af asynkrone operationer, selv under undtagelsesbehandling.

Ud over de grundlæggende asynkrone metoder findes der også en bred vifte af tredjepartsbiblioteker, som udvider funktionaliteten og gør arbejdet lettere eller mere effektivt. Disse inkluderer blandt andet ImageSharp til billedbehandling, Serilog til logging, AutoMapper til objektafbildning, FluentAssertions og FluentValidation til henholdsvis enhedstest og datavalidering samt QuestPDF til generering af PDF-filer. Valget af bibliotek bør baseres på både popularitet og relevans for det konkrete udviklingsbehov, og mange af disse biblioteker er aktive i open source-miljøet, hvilket sikrer vedvarende opdateringer og forbedringer.

Det er vigtigt at forstå, at async og await ikke blot er syntaktisk sukker, men fundamentale redskaber til at bygge moderne serverapplikationer, der kan håndtere mange samtidige forbindelser uden at ofre ydeevne. Man skal dog være opmærksom på korrekt brug af synkronisering, undgå unødvendige låse og foretrække atomare operationer via Interlocked-klassen, når det er muligt, for at undgå trådblokering og dødlås. I situationer med kompleks trådsikkerhed kan Mutex anvendes som et kraftigere værktøj til styring af kritiske sektioner.

Det er ligeledes væsentligt at forstå, hvordan man kan aflyse opgaver ved hjælp af cancellation tokens, hvilket giver bedre kontrol over langvarige asynkrone operationer og hjælper med at frigøre ressourcer hurtigt, når en opgave ikke længere er nødvendig.

Async-programmering forbedrer ikke kun serverens kapacitet men understøtter også en bedre brugeroplevelse, hvor responstider holdes lave, og applikationer forbliver responsive, selv under høj belastning. Den moderne udvikler bør derfor mestre disse teknikker og forstå de bagvedliggende principper for at kunne udnytte dem optimalt.

Hvordan implementere AutoMapper-konfigurationer og enheds-testning i .NET

Et grundlæggende scenarie er at bruge AutoMapper til at omdanne data fra et shopping cart-objekt til en opsummeringsmodel, som præsenterer en kunde og deres købsinformation på en forenklet måde. Her vil vi gennemgå et eksempel på, hvordan man opretter en sådan konfiguration og tester dens funktionalitet.

Først opretter vi en AutoMapper-konfiguration i et mapper-projekt, hvor vi definerer, hvordan data fra én model skal kortlægges til en anden. I et typisk tilfælde, som det der beskrives her, kan vi have et modelobjekt som en Cart, der indeholder detaljer som kundens navn og købte varer. Vi ønsker at mappe disse data til et simpelt Summary-view-model, der viser kundens navn og det samlede beløb for købet.

For eksempel, når testen fejler på grund af en Total-værdi, der ikke er mappet, kan vi tilføje en specifik regel for at beregne summen af varernes priser og opdatere konfigurationen med noget som følgende:

csharp
Copy code
MapperConfiguration config = new(cfg => {
    cfg.Internal().MethodMappingEnabled = false;
    cfg.CreateMap<Cart, Summary>()
        .ForMember(dest => dest.FullName, opt => opt.MapFrom(src => 
            string.Format("{0} {1}", src.Customer.FirstName, src.Customer.LastName)))
        .ForMember(dest => dest.Total, opt => opt.MapFrom(src => 
            src.Items.Sum(item => item.UnitPrice * item.Quantity)));
});

Med denne justering kan vi sikre, at Total-feltet bliver korrekt beregnet og mappet fra Cart-modellen til Summary-modellen.

Eksempelvis:

csharp
Copy code
Cart cart = new Cart(
    Customer: new Customer(FirstName: "John", LastName: "Smith"),
    Items: new List<LineItem> {

        new LineItem(ProductName: "Apples", UnitPrice: 0.49M, Quantity: 10),

        new LineItem(ProductName: "Bananas", UnitPrice: 0.99M, Quantity: 4)
    }
);
MapperConfiguration config = CartToSummaryMapper.GetMapperConfiguration();
IMapper mapper = config.CreateMapper();
Summary summary = mapper.Map<Summary>(cart);
Console.WriteLine($"Summary: {summary.FullName} spent {summary.Total}.");

Når man kører dette konsolprogram, vil man få output som viser, at "John Smith" har brugt 8,86 USD. Dette bekræfter, at konfigurationen og mappingen fungerer korrekt.

csharp
Copy code
string city = "London";
city.Should().StartWith("Lo")
    .And.EndWith("on")
    .And.Contain("do")
    .And.HaveLength(6);

På samme måde kan man lave tests for samlinger eller datoer ved at bruge samme fluent API. For eksempel kan vi teste, at en samling kun indeholder elementer af en bestemt længde:

csharp
Copy code
string[] names = new[] { "Alice", "Bob", "Charlie" };

names.Should().HaveCountLessThan(4)
    .And.OnlyContain(name => name.Length <= 6);

En vigtig pointe ved brug af AutoMapper og enhedstests i .NET er, at disse værktøjer, selvom de forenkler arbejdet, ikke eliminerer behovet for grundig fejlfinding og forståelse af, hvordan data flyder gennem applikationen. Det er essentielt at forstå, hvordan mapperen konfigureres, og hvordan man validerer resultaterne med passende tests. For at kunne diagnosticere problemer effektivt, kan det være nødvendigt at bruge avancerede features i AutoMapper og enheds-testbibliotekerne, og at have en god forståelse for, hvordan disse kan kombineres for at sikre applikationens korrekthed.