Hvordan fungerer det foruddefinerede ASP.NET Core MVC-projekt, og hvad skal man forstå bag kulisserne?

Det foruddefinerede ASP.NET Core MVC-projekt skaber en grundstruktur, der både letter hurtig udvikling og fremmer best practices inden for sikkerhed og organisering. Når projektet oprettes, konfigureres det automatisk med et sæt forbindelsesstrenge og miljøindstillinger, som gør det muligt at køre applikationen lokalt via Kestrel-webserveren eller IIS Express. Eksempelvis bruger systemet typisk enten en lokal SQL Server-database (mssqllocaldb) eller SQLite (app.db) afhængigt af konfigurationen i appsettings.json.

Det visuelle layout, som vises ved opstart af projektet i browseren, er baseret på Razor-filer (.cshtml), hvor servergenereret HTML kombineres med C#-kode. Navigationen tilpasser sig responsivt til skærmstørrelsen, og brugergrænsefladen inkluderer komponenter som registrering, login og brugeradministration. Bag denne funktionalitet ligger en solid integration med ASP.NET Core Identity – en ramme til autentificering og autorisation.

Ved brugerregistrering anvendes en DOI-struktur (Double-Opt-In), hvilket betyder, at en bekræftelsesmail sendes, og brugeren skal klikke på et link for at aktivere kontoen. I udviklingsmiljøet, hvor en e-mailudbyder endnu ikke er konfigureret, simuleres dette trin manuelt. Identitetssystemet kræver som standard en adgangskode, der indeholder mindst ét stort bogstav, ét tal og et specialtegn, hvilket afspejler et fokus på sikkerhed fra starten.

Når man har registreret sig og logget ind, præsenteres en administrationsside, hvor brugeren kan opdatere kontaktoplysninger, ændre adgangskode, aktivere to-faktor-autentificering og downloade eller slette sine data – funktioner der alle understøtter overholdelse af GDPR og anden moderne datalovgivning.

Projektets filstruktur er både logisk og velorganiseret, hvilket gør det lettere at opretholde og udvide applikationen. Controllers indeholder de klasser, der håndterer HTTP-anmodninger og genererer svar. Models rummer de dataobjekter, der sendes til visninger. Views indeholder de Razor-sider, der præsenteres i browseren. Data mappen er central for databasen og migreringer, som sikrer, at Identity-databasen er korrekt struktureret og opdateret. wwwroot fungerer som rodmappen for statiske filer såsom JavaScript, CSS og billeder.

Konfigurationer er fordelt mellem appsettings.json og appsettings.Development.json, hvor førstnævnte typisk bruges i produktion, mens den sidstnævnte bruges under lokal udvikling. Her defineres alt fra databasetilkobling til logningsniveauer.

Når man arbejder med dette projekt, er det essentielt at forstå det tætte samspil mellem konvention og konfiguration i ASP.NET Core. Projektets struktur er skabt til at følge MVC-arkitekturens principper og samtidig sikre, at sikkerhed, testbarhed og udvidelsesmuligheder er indlejret i koden fra starten. Dette udgangspunkt gør det muligt at fokusere på forretningslogikken og brugeroplevelsen, uden at man som udvikler skal opfinde fundamentale arkitektoniske løsninger fra bunden.

Det er væsentligt at forstå, at selvom denne skabelon giver en hurtig vej ind i udviklingen af webapplikationer, så er den samtidig kun en begyndelse. Den egentlige værdi ligger i, hvordan man tilpasser og udvider strukturen. For eksempel kræver en reel produktionsapplikation en korrekt konfigureret e-mailudbyder, en persistent database med backupstrategier, rollebaseret adgangsstyring og finjusterede sikkerhedsindstillinger. Desuden bør logging, fejlhåndtering og brugervenlighed (UI/UX) løbende forbedres og overvåges.

Det er også vigtigt at forstå, at launchSettings.json kun er relevant i udviklingsmiljøet – disse oplysninger deployeres ikke til produktion, hvilket kræver en separat opsætning af miljøvariabler og konfigurationsstrategier til at beskytte følsomme oplysninger som forbindelsesstrenge og API-nøgler.

Hvordan bygger man et Blazor WebAssembly-websted med Server API og håndterer komplekse datakomponenter?

Først og fremmest er det nødvendigt at overveje projektstrukturen, hvor projekterne for server, klient og delt kode er placeret i separate mapper. Denne struktur betyder, at de relative stier til delt kode skal være tre niveauer op fra projektet, for eksempel "......", hvilket kan være en kilde til forvirring, hvis man ikke er opmærksom på den dybere mappehierarki.

csharp
Copy code
using Microsoft.AspNetCore.Mvc; // [FromServices]
using Packt.Shared; // AddNorthwindContext extension method
using System.Text.Json.Serialization; // ReferenceHandler
using HttpJsonOptions = Microsoft.AspNetCore.Http.Json.JsonOptions;

csharp
Copy code
builder.Services.Configure<HttpJsonOptions>(options =>
{
    options.SerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;
});

En anden vigtig konfiguration er at registrere databasekonteksten i afhængighedsinjektionen, hvilket gøres før Build-metoden kaldes. Det kan gøres som følger:

csharp
Copy code
builder.Services.AddNorthwindContext();

Når dette er på plads, kan man begynde at definere webservice-endpoints. For eksempel kan et GET-endpoint til at hente alle ansatte se ud som følger:

csharp
Copy code
app.MapGet("api/employees", ([FromServices] NorthwindContext db) =>
    Results.Json(db.Employees))
    .WithName("GetEmployees")
    .Produces(StatusCodes.Status200OK);

Der er også behov for endpoints, der kan håndtere forespørgsler baseret på en bestemt medarbejders ID eller et land. Endelig kan man tilføje et POST-endpoint til at oprette nye medarbejdere, som vil returnere en oprettet meddelelse med den nye medarbejders ID:

csharp
Copy code
app.MapPost("api/employees", async ([FromBody] Employee employee, [FromServices] NorthwindContext db) =>

{
    db.Employees.Add(employee);
    await db.SaveChangesAsync();
    return Results.Created($"api/employees/{employee.EmployeeId}", employee);
})
.Produces(StatusCodes.Status201Created);

Når webservicen er opsat og kan håndtere grundlæggende dataoperationer, er det tid til at opbygge klientapplikationen. I klientprojektet tilføjes referencer til de nødvendige komponenter som QuickGrid til at vise dataene i et grid-format. I Northwind.BlazorWasm.Client.csproj-filen tilføjes følgende:

xml
Copy code
<PackageReference Include="Microsoft.AspNetCore.Components.QuickGrid" Version="x.y.z" />

Dette komponent er en simpel grid-komponent til Blazor, der gør det nemt at vise tabeller af data på en effektiv måde. Derudover skal referencen til Northwind-enhedsprojektet for SQL Server også tilføjes, så de nødvendige modeller er tilgængelige.

Når projektet er bygget, er næste skridt at konfigurere HTTP-klienten i Program.cs i klientprojektet. Dette sikrer, at klienten kan kommunikere med serverprojektet, som hoster webservice-API'et:

csharp
Copy code
builder.Services.AddHttpClient("Northwind.BlazorWasm.ServerAPI", client =>
{
    client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress);
});

Når HTTP-klienten er konfigureret, er det muligt at hente data fra serveren og vise dem i et QuickGrid-komponent i Blazor-komponenterne. Et eksempel på hvordan man henter og viser medarbejdere kan se således ud:

csharp
Copy code
@code {

    [Parameter] public string? Country { get; set; }
    private IQueryable<Employee>? employees;

    protected override async Task OnParametersSetAsync()

    {
        Employee[]? employeesArray = null;
        JsonSerializerOptions jsonOptions = new()
        {
            ReferenceHandler = ReferenceHandler.Preserve,
            PropertyNameCaseInsensitive = true
        };
        HttpClient client = httpClientFactory.CreateClient("Northwind.BlazorWasm.ServerAPI");
        string path = "api/employees";
        try
        {
            employeesArray = await client.GetFromJsonAsync<Employee[]>(path, jsonOptions);
        }
        catch (Exception ex)
        {
            Console.WriteLine($"{ex.GetType()}: {ex.Message}");
        }
        if (employeesArray != null)
        {
            employees = employeesArray.AsQueryable();
            if (!string.IsNullOrWhiteSpace(Country))
            {
                employees = employees.Where(emp => emp.Country == Country);
            }
        }
    }
}

Her er det værd at bemærke, at selvom webservicen tillader hentning af ansatte filtreret efter land, benyttes client-side filtrering på klienten for at undgå unødvendige serveranmodninger. Dette kan hjælpe med at reducere serverens belastning og forbedre brugeroplevelsen.

Når alt er på plads, kan man starte serverprojektet uden fejlfinding og begynde at bruge Blazor WebAssembly-applikationen med den etablerede funktionalitet.

Endtext

Hvordan implementere tovej Data Binding i MVVM med .NET MAUI

MVVM (Model-View-ViewModel) er et designmønster, der bruges til at adskille præsentationens logik fra forretningslogikken i applikationer. Det er en udvidelse af MVC (Model-View-Controller), hvor "View" og "Model" er stadig centrale komponenter, men "ViewModel" introduceres for at håndtere præsentationen af data og give et interface til interaktion med visningen. I .NET MAUI (Multi-platform App UI) er det vigtigt at forstå, hvordan tovej data binding fungerer i dette mønster for at skabe dynamiske og interaktive brugergrænseflader.

I MVVM-modellen er der tre grundlæggende komponenter:

• Model: En klasse, der repræsenterer de data, som applikationen arbejder med, som f.eks. data hentet fra en database.

• View: Det grafiske brugerinterface, der viser dataene til brugeren og giver mulighed for at interagere med dem.

• ViewModel: En klasse, der repræsenterer de datafelter, handlinger og begivenheder, som bindes til visningen.

I et typisk MVC-design er dataene, der sendes til visningen, normalt kun læst og uforanderlige. Dette kan føre til en statisk visning af data. I MVVM er situationen anderledes. ViewModelen understøtter tovej data binding, hvilket betyder, at ændringer i både model og visning kan synkroniseres. Dette kræver mekanismer, der gør det muligt for visningen at blive opdateret automatisk, når dataene ændres.

INotifyPropertyChanged Interface

INotifyPropertyChanged er ansvarlig for at notificere brugergrænsefladen om ændringer i modeldata. Når en egenskab i modelklassen ændres, udløses en begivenhed, der informerer visningen om, at dataene er blevet opdateret.

Når du opretter en egenskab i en klasse, skal du hæve begivenheden PropertyChanged, som angiver, at en værdi er blevet opdateret. Det er vigtigt, at visningen kan reagere på disse opdateringer for at vise de nyeste data.

Eksemplet nedenfor viser, hvordan en klasse kan implementere INotifyPropertyChanged:

csharp
Copy code
public class CustomerDetailViewModel : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    private string customerId;
    public string CustomerId
    {
        get => customerId;
        set
        {
            customerId = value;
            OnPropertyChanged();
        }
    }
    private string companyName;
    public string CompanyName
    {
        get => companyName;
        set
        {
            companyName = value;
            OnPropertyChanged();
        }
    }
    private void OnPropertyChanged([CallerMemberName] string propertyName = "")
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

ObservableCollection og INotifyCollectionChanged

Relateret til INotifyPropertyChanged er INotifyCollectionChanged, som anvendes af ObservableCollection. Denne klasse giver besked, når elementer tilføjes, fjernes eller opdateres i en samling. Når en ObservableCollection bindes til en kontrol som f.eks. ListView eller TreeView, opdateres brugergrænsefladen automatisk for at afspejle ændringer i samlingen.

csharp
Copy code
public class CustomersListViewModel : ObservableCollection<CustomerDetailViewModel>
{
    public void LoadSampleData()
    {

        this.Add(new CustomerDetailViewModel { CustomerId = "ALFKI", CompanyName = "Alfreds Futterkiste" });

        this.Add(new CustomerDetailViewModel { CustomerId = "ANATR", CompanyName = "Ana Trujillo Emparedados y helados" });
    }
}

I dette eksempel er CustomersListViewModel en samling af CustomerDetailViewModel-objekter. Når en kunde tilføjes eller fjernes fra samlingen, opdateres ListView i visningen automatisk.

To-vejs Data Binding i ViewModel

Et eksempel på en CustomerDetailViewModel, der understøtter tovej data binding, er som følger:

csharp
Copy code
public class CustomerDetailViewModel : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    private string city;
    public string City
    {
        get => city;
        set
        {
            city = value;
            NotifyPropertyChanged();
            NotifyPropertyChanged(nameof(Location));
        }
    }
    private string country;
    public string Country
    {
        get => country;
        set
        {
            country = value;
            NotifyPropertyChanged();
            NotifyPropertyChanged(nameof(Location));
        }
    }
    public string Location
    {
        get => $"{City}, {Country}";
    }
    private void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

Vigtige Overvejelser ved Implementering af MVVM i .NET MAUI

Når du arbejder med MVVM og tovej data binding i .NET MAUI, er det vigtigt at huske på flere ting:

1. Ydelse og Opdatering: Da data binding kan føre til hyppige opdateringer af visningen, bør du overveje at optimere, hvordan og hvornår ændringer foretages for at undgå unødvendige opdateringer, især på mobile enheder.

2. Kompleksitet i Store Projekter: I større applikationer kan MVVM-strukturen blive kompleks. Det er vigtigt at holde ViewModeler små og fokuserede på deres ansvar for at undgå, at de bliver for tunge at vedligeholde.

3. Brug af NuGet-pakker: .NET tilbyder flere nuget-pakker, som kan hjælpe med at lette arbejdet med MVVM, som f.eks. CommunityToolkit.MVVM, der giver funktionalitet til at implementere binding og notification uden at skulle skrive meget boilerplate-kode.

Hvordan genereres en PDF med billeder og datamodeller i .NET med QuestPDF?

Først oprettes en mappe i projektet, typisk kaldet “images”, hvor kategoribillederne placeres. Disse billeder skal tilføjes til projektet og sættes til altid at blive kopieret til output-mappen under build-processen, således at de er tilgængelige ved kørsel. Dette sikrer, at PDF-genereringen kan finde billederne relativt til programmets kørselstidspunkt. Indstillingerne for kopiering styres i projektets properties og i projektfilen (.csproj), hvor man specificerer, at billedfilerne skal kopieres ved hver build.

Dernæst importeres nødvendige namespaces og biblioteker i programmet. En typisk opgave er at oprette en datamodel, der repræsenterer indholdet af kataloget, for eksempel en liste af kategorier med ID og navn. Denne model overføres til en dokumentklasse, som implementerer QuestPDF’s dokumentinterface. Dokumentklassen styrer, hvordan indholdet rendres i PDF’en, herunder layout og inkludering af billeder.

Når dokumentet er konstrueret, kan PDF-filen genereres ved at kalde en metode som GeneratePdf med det ønskede filnavn. For at forbedre brugeroplevelsen forsøger programmet herefter at åbne den genererede PDF automatisk ved hjælp af operativsystemets standardprogram til PDF-filer. Dette kan dog variere i kompleksitet afhængig af platformen, og eksemplet henvender sig især til Windows, hvor “explorer.exe” kan anvendes til åbning af filer. På andre systemer kræver det ofte mere specifik håndtering.

Anvendelsen af tredjepartsbiblioteker som QuestPDF er blot et eksempel på, hvordan komplekse opgaver i .NET kan håndteres effektivt ved at bygge oven på veludviklede komponenter. Ud over PDF-generering findes andre populære biblioteker som ImageSharp til billedmanipulation, Serilog til struktureret logning og FluentValidation til validering, der tilsammen danner et solidt fundament for udvikling af professionelle .NET-applikationer.

For fuldt ud at forstå denne proces er det væsentligt at have indsigt i, hvordan .NET-projekter organiseres, herunder hvordan filer indlæses og kopieres ved build, samt hvordan tredjepartsbiblioteker integreres. At kunne modellere data korrekt og omsætte dem til visuelle dokumenter kræver en forståelse af både dataarkitektur og UI-designprincipper. Desuden bør man kende til platformsspecifikke forskelle i filhåndtering og processtyring, hvilket kan påvirke brugeroplevelsen ved åbning af filer efter generering.

Samtidig er det vigtigt at forstå versionering og vedligeholdelse af afhængigheder, da tredjepartsbiblioteker ofte opdateres med nye funktioner og fejlrettelser, hvilket kan påvirke stabiliteten i applikationen. At følge semantisk versionering og holde øje med ændringer i bibliotekerne sikrer, at integrationerne forbliver konsistente.

Hvordan arbejde med kulturer i internationalisering og lokalisering?

Internationalisering er en proces, hvor man sikrer, at ens kode kan fungere korrekt på tværs af verdenen. Denne proces omfatter to hoveddele: globalisering og lokalisering, som begge har at gøre med, hvordan man arbejder med kulturer.

Globalisering handler om at skrive kode, der kan rumme flere sprog og regionale kombinationer. En kultur består af en kombination af et sprog og en region, og det er vigtigt at forstå begge aspekter. For eksempel er dato- og valutaformater forskellige i Quebec og Paris, selvom de begge taler fransk. Derfor er det nødvendigt for koden at kende både sproget og regionen for korrekt at håndtere formater som datoer og valutaer. International Organization for Standardization (ISO) har defineret koder for alle kulturkombinationer. For eksempel betyder koden da-DK, at da står for dansk sprog og DK for Danmark, mens fr-CA betyder fransk sprog og CA for Canada.

Lokalisering, derimod, handler om at tilpasse brugergrænsefladen til at understøtte et bestemt sprog. Det kan være så simpelt som at ændre teksten på en knap fra "Close" (på engelsk) til "Fermer" (på fransk). Lokalisering fokuserer primært på sproget, og selvom det ikke nødvendigvis altid kræver kendskab til regionen, er der dog undtagelser. For eksempel, de engelske standarder "en-US" og "en-GB" kræver specifik viden om regionen.

Når man arbejder med kulturer i internationalisering, er det væsentligt at have værktøjer til at detektere og ændre kulturen under kørslen af applikationen. System.Globalization-namespace indeholder nyttige typer som CultureInfo og RegionInfo, der giver mulighed for at hente og ændre kulturinformation på et globalt niveau.

I et typisk scenario, hvor man skriver kode til internationalisering, kan man bruge følgende eksempel:

csharp
Copy code
CultureInfo globalization = CultureInfo.CurrentCulture;

CultureInfo localization = CultureInfo.CurrentUICulture;
WriteLine("Den nuværende globalisering kultur er {0}: {1}", globalization.Name, globalization.DisplayName);
WriteLine("Den nuværende lokalisering kultur er {0}: {1}", localization.Name, localization.DisplayName);

Dette eksempel henter de aktuelle kulturer, der er i brug i applikationen, og viser oplysninger om dagen, måneden og valutaen baseret på den kultur, der er valgt. Derudover kan du se hvordan applikationen interagerer med brugerinput og hvordan det reagerer på ændring af kultur under kørslen.

Når man ændrer kulturen i koden, f.eks. ved at bruge en ISO kulturkode som "da-DK" (dansk, Danmark), vil datoformaterne, ugedagene, og selv talformaterne ændre sig i henhold til de regionale indstillinger.

Valutaformater og numeriske systemer er også vigtige aspekter af internationalisering. Den måde, penge og tal formateres på, kan variere afhængigt af land. Eksempelvis bruger Storbritannien et komma som tusindtalsseparator, mens Danmark bruger et punktum. Sådanne forskelle skal håndteres omhyggeligt for at sikre korrekt visning af beløb i brugerfladen.

Derudover er sprog og lokale idiomer vigtige at forstå. Selvom du oversætter knapper og meddelelser, er det ikke altid nok. Sprog har mange nuancer, og nogle udtryk fungerer måske ikke godt i en anden kultur. En grundig undersøgelse af kulturelle forskelle og oversættelsesmetoder er nødvendig for at sikre, at din applikation ikke kun fungerer teknisk, men også kommunikerer effektivt på tværs af forskellige sprog og kulturer.

Når brugeren for eksempel indtaster en kulturkode som "da-DK", vil applikationen ændre sine indstillinger for at vise danske datoer, valutaer og format. Dette kan gøres dynamisk, så programmet kan tilpasse sig den specifikke kultur, brugeren arbejder med.

Endelig er det vigtigt at forstå, at internationalisering ikke kun handler om at oversætte sprog, men om at tage højde for alle de små kulturelle forskelle, der kan have stor betydning for brugeroplevelsen. Korrekt internationalisering kræver en systematisk tilgang, hvor man konstant tester og justerer applikationen for at sikre, at den fungerer globalt og ikke blot lokalt.