Dela via


Validering på klientsidan (validering i presentationsskikten)

Tips

Det här innehållet är ett utdrag från eBook, .NET Microservices Architecture for Containerized .NET Applications, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

.NET-mikrotjänstarkitektur för containerhanterade .NET-applikationer e-bok omslagsminiatyr.

Även om sanningskällan är domänmodellen och du i slutändan måste ha validering på domänmodellnivå kan valideringen fortfarande hanteras både på domänmodellnivå (serversidan) och användargränssnittet (klientsidan).

Validering på klientsidan är en bra bekvämlighet för användarna. Det sparar tid som de annars skulle spendera på att vänta på en tur och retur till servern som kan returnera valideringsfel. I affärstermer multipliceras även några bråkdelar av sekunder hundratals gånger varje dag med mycket tid, kostnader och frustration. Enkel och omedelbar validering gör det möjligt för användare att arbeta mer effektivt och producera indata och utdata av bättre kvalitet.

På samma sätt som vymodellen och domänmodellen skiljer sig åt kan validering av visningsmodell och domänmodellverifiering vara liknande men ha ett annat syfte. Om du är orolig för DRY (principen Upprepa inte själv) bör du tänka på att återanvändning av kod i det här fallet också kan innebära koppling, och i företagsprogram är det viktigare att inte koppla serversidan till klientsidan än att följa DRY-principen.

Även när du använder validering på klientsidan bör du alltid verifiera dina kommandon eller mata in DTU:er i serverkoden, eftersom server-API:erna är en möjlig attackvektor. Vanligtvis är det bästa valet att göra båda, för om du har ett klientprogram, ur ett UX-perspektiv, är det bäst att vara proaktiv och inte tillåta att användaren anger ogiltig information.

Därför validerar du vanligtvis ViewModels i kod på klientsidan. Du kan också verifiera klientutdata-DTU:er eller kommandon innan du skickar dem till tjänsterna.

Implementeringen av verifiering på klientsidan beror på vilken typ av klientprogram du skapar. Det blir annorlunda om du verifierar data i ett MVC-webbprogram med det mesta av koden i .NET jämfört med ett SPA-webbprogram med valideringskoden i JavaScript eller TypeScript.

Ytterligare resurser

Validering i ASP.NET Core-appar

Validering i SPA-webbappar (Angular 2, TypeScript, JavaScript, Blazor WebAssembly)

Sammanfattningsvis är dessa de viktigaste begreppen när det gäller validering:

  • Entiteter och aggregeringar bör framtvinga sin egen konsekvens och vara "alltid giltiga". Aggregerade rötter ansvarar för konsekvens mellan flera entiteter inom samma aggregering.

  • Om du tror att en entitet måste ange ett ogiltigt tillstånd bör du överväga att använda en annan objektmodell, till exempel genom att använda en tillfällig DTO tills du skapar den slutliga domänentiteten.

  • Om du behöver skapa flera relaterade objekt, till exempel en aggregering och de bara är giltiga när alla har skapats, bör du överväga att använda mönstret Fabrik.

  • I de flesta fall är det bra att ha redundant validering på klientsidan eftersom programmet kan vara proaktivt.