Introduktion till .NET MAUI

Dricks

Det här innehållet är ett utdrag från eBook, Enterprise Application Patterns Using .NET MAUI, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

Ladda ned PDF

Oavsett plattform står utvecklare av företagsappar inför flera utmaningar:

• Appkrav som kan ändras över tid.
• Nya affärsmöjligheter och utmaningar.
• Löpande feedback under utvecklingen som avsevärt kan påverka appens omfång och krav.

Med dessa i åtanke är det viktigt att skapa appar som enkelt kan ändras eller utökas med tiden. Det kan vara svårt att utforma för en sådan anpassningsbarhet eftersom det krävs en arkitektur som gör att enskilda delar av appen kan utvecklas och testas separat utan att påverka resten av appen.

Många företagsappar är tillräckligt komplexa för att kräva mer än en utvecklare. Det kan vara en viktig utmaning att bestämma hur en app ska utformas så att flera utvecklare kan arbeta effektivt på olika delar av appen oberoende av varandra, samtidigt som de ser till att delarna samlas sömlöst när de integreras i appen.

Den traditionella metoden för att utforma och skapa en app resulterar i vad som kallas en monolitisk app, där komponenterna är tätt kopplade utan någon tydlig separation mellan dem. Vanligtvis leder den här monolitiska metoden till appar som är svåra och ineffektiva att underhålla, eftersom det kan vara svårt att lösa buggar utan att bryta andra komponenter i appen, och det kan vara svårt att lägga till nya funktioner eller ersätta befintliga funktioner.

Ett effektivt botemedel mot dessa utmaningar är att partitionera en app i diskreta, löst kopplade komponenter som enkelt kan integreras i en app. En sådan metod erbjuder flera fördelar:

• Det gör att enskilda funktioner kan utvecklas, testas, utökas och underhållas av olika individer eller team.
• Det främjar återanvändning och en ren uppdelning av problem mellan appens horisontella funktioner, till exempel autentisering och dataåtkomst, och de vertikala funktionerna, till exempel appspecifika affärsfunktioner. Detta gör det enklare att hantera beroenden och interaktioner mellan appkomponenter.
• Det hjälper till att upprätthålla en uppdelning av roller genom att låta olika individer, eller team, fokusera på en specifik uppgift eller funktion enligt deras expertis. I synnerhet ger det en renare separation mellan användargränssnittet och appens affärslogik.

Det finns dock många problem som måste lösas när du partitionerar en app i diskreta, löst kopplade komponenter. Dessa kan vara:

• Bestämma hur du ska tillhandahålla en ren uppdelning av problem mellan användargränssnittskontrollerna och deras logik. Ett av de viktigaste besluten när du skapar en .NET MAUI Enterprise-app är om du vill placera affärslogik i kod bakom filer, eller om du vill skapa en ren uppdelning av problem mellan användargränssnittskontrollerna och deras logik, för att göra appen mer underhållsbar och testbar. Mer information finns i Model-View-ViewModel.
• Avgöra om du vill använda en container för beroendeinmatning. Beroendeinmatningscontainrar minskar beroendekopplingen mellan objekt genom att tillhandahålla en möjlighet att konstruera instanser av klasser med deras beroenden inmatade och hantera deras livslängd baserat på containerns konfiguration. Mer information finns i Beroendeinmatning.
• Välja mellan plattformsbaserad händelsehantering och löst kopplad meddelandebaserad kommunikation mellan komponenter som är obekväma att länka efter objekt- och typreferenser. Mer information finns i Introduktion till kommunikation mellan löst kopplade komponenter.
• Bestämma hur du ska navigera mellan sidor, inklusive hur du anropar navigering och var navigeringslogik ska finnas. Mer information finns i Navigering.
• Fastställa hur användarens indata ska verifieras för korrekthet. Beslutet måste innehålla hur användarens indata ska verifieras och hur användaren ska meddelas om valideringsfel. Mer information finns i Validering.
• Bestämma hur du ska utföra autentisering och hur du skyddar resurser med auktorisering. Mer information finns i Autentisering och auktorisering.
• Fastställa hur du får åtkomst till fjärrdata från webbtjänster, inklusive hur du hämtar data på ett tillförlitligt sätt och hur du cachelagrar data. Mer information finns i Komma åt fjärrdata.
• Bestämma hur appen ska testas. Mer information finns i Enhetstestning.

Den här guiden ger vägledning om dessa problem och fokuserar på kärnmönster och arkitektur för att skapa en plattformsoberoende företagsapp med hjälp av .NET MAUI. Vägledningen syftar till att hjälpa till att skapa anpassningsbar, underhållsbar och testbar kod genom att hantera vanliga scenarier för utveckling av .NET-företagsappar MAUI och genom att separera problemen med presentation, presentationslogik och entiteter genom stöd för MVVM-mönstret (Model-View-ViewModel).

Programexempel

Den här guiden innehåller ett exempelprogram, eShop, som är en onlinebutik som innehåller följande funktioner:

• Autentisera och auktorisera mot en serverdelstjänst.
• Bläddra i en katalog med objekt.
• Filtrera katalogen.
• Beställa objekt från katalogen.
• Visa användarens orderhistorik.
• Konfiguration av inställningar.

Exempel på programarkitektur

Nedan visas en översikt över exempelprogrammets arkitektur.

Exempelprogrammet levereras med:

• .NET Aspire App Hosting & Orchestration
• En Blazor-webbapp utvecklad med ASP.NET Core.
• En app för flera plattformar som utvecklats med .NET MAUI, som stöder iOS, Android, macOS via Mac Catalyst och Windows.

Exempelprogrammet innehåller följande serverdelstjänster:

• En identitetsmikrotjänst som använder ASP.NET Core Identity och IdentityServer.
• En katalogmikrotjänst, som är en datadriven crud-tjänst (create, read, update, delete) som använder en SQL Server-databas med EntityFramework Core.
• En beställningsmikrotjänst, som är en domändriven tjänst som använder domändrivna designmönster.
• En korgmikrotjänst, som är en datadriven CRUD-tjänst som använder Redis Cache.

Dessa serverdelstjänster implementeras som mikrotjänster med ASP.NET Core och distribueras som unika containrar med .NET Aspire. Tillsammans kallas dessa serverdelstjänster för eShop-referensprogrammet. Klientappar kommunicerar med serverdelstjänsterna via ett REST-webbgränssnitt (Representational State Transfer). Mer information om mikrotjänster och containrar finns i Containerbaserade mikrotjänster.

App för flera plattformar

Den här guiden fokuserar på att skapa plattformsoberoende företagsappar med hjälp av .NET MAUIoch använder eShop-multiplattformsappen som exempel. Bilden nedan visar sidorna från eShop-appen för flera plattformar som tillhandahåller de funktioner som beskrevs tidigare.

Multiplattformsappen använder de serverdelstjänster som tillhandahålls av eShop-referensprogrammet. Den kan dock konfigureras för att använda data från falska tjänster för dem som vill undvika att distribuera serverdelstjänsterna.

EShop-appen för flera plattformar använder följande .NET-funktioner MAUI :

• XAML
• Kontroller
• Bindningar
• Omvandlare
• Format
• Animeringar
• Kommandon
• Funktioner
• Utlösare
• Effekter
• Anpassade kontroller

Mer information om den här funktionen finns i .NET-dokumentationenMAUI.

Dessutom tillhandahålls enhetstester för några av klasserna i eShop-appen för flera plattformar.

Applösning för flera plattformar

EShop-applösningen för flera plattformar organiserar källkoden och andra resurser i flera projekt. Alla mobila kärnkomponenter finns i ett enda projekt med namnet eShopContainers. Det här är en funktion som introduceras med .NET 6 som gör att ett projekt kan rikta in sig på flera utdata som hjälper till att eliminera behovet av flera plattformsprojekt som vi skulle ha använt i Xamarin.Forms och tidigare .NET-versioner. Ytterligare ett projekt ingår för enhetstestning.

Även om det här projektet har alla sina komponenter lagrade i ett enskilt projekt, är det värt att överväga att dela upp det i flera projekt baserat på dina behov. Om du till exempel har flera implementeringar av tjänstleverantörer baserade på en tjänst med egna beroenden kan det vara klokt att dela upp implementeringarna av tjänstleverantören i ett eget separat projekt. Bra kandidater för projektavgränsning är delade modeller, tjänstimplementeringar, API-klientkomponenter, databas- eller cachelagringslager. Varje plats där du känner att företaget kan återanvända en komponent i ett annat projekt är en potentiell kandidat för separation. Dessa projekt kan sedan paketeras via NuGet för enkel distribution och versionshantering.

Alla projekt använder mappar för att organisera källkoden och andra resurser i kategorier. Klasserna från eShop-appen för flera plattformar kan återanvändas i valfri .NET-app MAUI med liten eller ingen ändring.

eShop-projekt

EShop-projektet innehåller följande mappar:

Mapp	beskrivning
Animationer	Innehåller klasser som gör att animeringar kan användas i XAML.
Beteenden	Innehåller beteenden som exponeras för visningsklasser.
Kontroller	Innehåller anpassade kontroller som används av appen.
Omvandlare	Innehåller värdekonverterare som tillämpar anpassad logik på en bindning.
Undantag	Innehåller den anpassade ServiceAuthenticationException.
Tillägg	Innehåller tilläggsmetoder för klasserna VisualElement och IEnumerable<T> .
Hjälpare	Innehåller hjälpklasser för appen.
Modeller	Innehåller modellklasserna för appen.
Egenskaper	Innehåller AssemblyInfo.cs, en .NET-sammansättningsmetadatafil.
Tjänster	Innehåller gränssnitt och klasser som implementerar tjänster som tillhandahålls till appen.
Utlösare	Innehåller BeginAnimation-utlösaren, som används för att anropa en animering i XAML.
Valideringar	Innehåller klasser som ingår i validering av dataindata.
ViewModels	Innehåller programlogik som exponeras för sidor.
Vyer	Innehåller sidorna för appen.

Sammanfattning

Microsofts plattformsoberoende plattformsoberoende apputvecklingsverktyg och plattformar ger en omfattande lösning för B2E-, B2B- och B2C-mobilappar, vilket ger möjlighet att dela kod på alla målplattformar (iOS, macOS, Android och Windows) och bidra till att sänka den totala ägandekostnaden. Appar kan dela sitt användargränssnitt och sin applogikkod, samtidigt som de behåller den inbyggda plattformskänslan.

Utvecklare av företagsappar står inför flera utmaningar som kan förändra appens arkitektur under utvecklingen. Därför är det viktigt att skapa en app så att den kan ändras eller utökas med tiden. Det kan vara svårt att utforma en sådan anpassningsbarhet, men det innebär vanligtvis att partitionera en app i diskreta, löst kopplade komponenter som enkelt kan integreras i en app.