• Forside
• Idékassen
• Artikler/erfaringer
• Links
• Om softspot

• ASP 3.0
  • Forretningslag og validering
  • Seperation af forretningslag og databaselag
  • Caching i session
  • Callbacks i ASP
  • Klasser on-the-fly
  • Konstruktører i VBS
  • Brugen af XMLDocument
  • Generering af JSON
  • Events i ASP
  • Events i ASP - 2
  • Skjul filer på dit site
  • Den Kinesiske æske
  • Siteindstillinger i en fil
  • Global.asa til autologin
  • VBS-klasser til indkapsling
• HTML og CSS
• JavaScript
• Umbraco
• ASP.NET

Forretningslag og validering 

Der er flere grunde til hvorfor man skal prøve at inddele sine systemer i lag (f.eks. indkapsling for genanvendelighed og isolering, testbarhed, overskuelighed m.fl.). I VBScript er der forskellige måder at kode på, den mest populære er nok funktionsorienteret. Jeg vil dog kigge lidt på muligheden for at benytte klasser til at skabe lidt mere struktur og øge muligheden for at højne kvaliteten af den kode der produceres i dette sprog.

En af udfordringerne med klassisk ASP er, at få testet sin kode, da mange (mindre projekter i det mindste) har tendens til at skabe en stor afhængighed af mellem brugergrænsefladen og forretningsregler/-logik. Typisk opnås dette ved at lægge regler for validering sammen med koden for rendering af skærmbilleder (HTML-koden) i samme fil. Det har flere ulemper, hvoraf et par af dem er

• besværliggør teamwork omkring en given side (dels indenfor udviklingsteamet, dels på tværs af design- og udviklingsteam)
• besværliggør vedligeholdelsen, da forretningsregler har det med at ville anvendes flere steder
• mindsker overblikket over en given funktionalitet, da den er mixet sammen med GUI-logik

Større seperation og testbarhed

Et middel er som nævnt at benytte en klasse til at samle logik vedr. et bestemt forretningsområde i en eller flere klasser, som sørger for at tingene kun skal vedligeholdes et sted og, som en sidegevinst, sørger for at det bliver væsentlig mere testbart. Det med test kommer jeg tilbage til i en anden artikel...

Nu vil jeg kigge lidt på hvordan man kan koble validering på et forretningsobjekt. Jeg tager udgangspunkt i at der er to niveauer af validering, dels er der inputvalidering, dels forretningsvalidering.

Inputvalidering er validering af formatet af de oplysninger som brugere angiver i brugergrænsefladen og sender til serveren. Den validering bør derfor altid foretages. Denne validering er baseret på strenge, da input typisk kommer i strengformat fra formularer. Denne validering skal være tilgængelig i den offentlige grænseflade på objektet, så den kan aktiveres i forbindelse med opdatering af objektets data.

Forretningsvalidering er den validering som sikrer at data har nogle forretningsmæssige fornuftige værdier, dvs. skal en persons alder ligge mellem 18 og 25, så er dette en forretningsregel, hvor inputvalideringens rolle er at validere om alderen er numerisk.

Lad os dykke!

Lad os kigge på et konkret eksempel, så vi kan få lidt snask på fingrene...

class CPerson
  private m_Navn
  private m_Alder
  private m_Valideringsfejl

  private sub Class_Initialize()
    ' opret en liste til valideringsfejl
    set m_Valideringsfejl = Server.CreateObject("Scripting.Dictionary")
    ' Sørg for at egenskaberne på objektet har de korrekte typer fra starten
    ' ...men ikke nødvendigvis forretningsmæssigt gyldigt indhold!
    m_Navn = ""
    m_Alder = 0
  end sub

  '----------------------------------------------------------------
  public property get Navn: Navn = m_Navn: end property
  public property let Navn(value): m_Navn = CStr(value): end property

  public property get Alder: Alder = m_Alder: end property
  public property let Alder(value): m_Alder = CInt(value): end property

  public property get Valideringsfejl
    set Valideringsfejl = m_Valideringsfejl
  end property

  '----------------------------------------------------------------
  ' Her foretages den forretningsmæssige validering af objektet
  ' Der returneres true hvis der ikke er nogen valideringsfejl.
  '----------------------------------------------------------------
  private function Valider(resetList)
    if resetList then
      ' Slet listen med valideringsfejl inden valideringen foretages
      call Valideringsfejl.RemoveAll()
    end if

    if Len(Navn) = 0 then
      call Valideringsfejl.Add("NavnEjUdfyldt", "Navnet skal være udfyldt.")
    end if

    if Len(Navn) > 50 then
      call Valideringsfejl.Add("NavnForLangt", "Navnet må højst være 50 tegn.")
    end if

    if Alder < 18 or Alder > 25 then
      call Valideringsfejl.Add("AlderUgyldig", _
               "Alderen skal være mellem 18 og 25 år")
    end if

    Valider = Valideringsfejl.Count = 0
  end function

  '----------------------------------------------------------------
  ' Valider input fra omverdenen
  '----------------------------------------------------------------
  public function ValiderInput( _
    Navn, _
    Alder _
  )
    ' Slet listen med valideringsfejl inden valideringen foretages
    call Valideringsfejl.RemoveAll()

    if not IsEmpty(Navn) then
      if TypeName(Navn) <> "String" then
        call Valideringfejl.Add("NavnType", "Personens navn skal være en tekst.")
      else
        me.Navn = Navn
      end if
    end if

    If not IsEmpty(Alder) then
      if not IsNumeric(Alder) then
        call Valideringsfejl.Add("AlderNonnumber", _
                 "Personens alder skal være et tal.")
      else
        me.Alder = Alder
      end if
    end if

    ' Kald den forretningsmæssige validering af objektet, så valideringsfejl-listen
    ' kommer til at indeholde alle fejl objektet måtte have...
    call Valider(false)

    ValiderInput = Valideringsfejl.Count = 0
  end function

  '----------------------------------------------------------------
  ' Her foretages den forretningsmæssige validering af objektet
  ' inden objektets data kan gemmes...
  '----------------------------------------------------------------
  public sub Gem()
    if Valider(true) then
      ' Gør det der skal til for at gemme personens data til senere
      ' - f.eks. i en database
      dim pdo
      set pdo = new CPersonDO
      call pdo.Gem(me)
    else
      err.Raise 10001, "CPerson.Gem", "Personens oplysninger er ikke gyldige"
    end if
  end sub
end class

Der er et par pointer som skal observeres i ovenstående eksempel.

ValiderInput benyttes som første trin i valideringen, samt som initiering af objektets værdier. Ved at sende objektets egenskaber ind som parametre til funktionen, kan man undlade at "input"-validere enkelte felter. Dette kunne f.eks. være interessant i tilfælde hvor man ønsker at opdatere en delmænde af et objekts værdier. Dette vil ikke få nogen effekt på den forretningsmæssige validering, da den altid udføres i forbindelse med kaldet til Gem (Gem bør som udgangspunkt være den eneste måde at få objektets data ned i databasen!) og vil derfor, hvis der er validitetsproblemer, give en fejl.

De offentlige egenskaber er den direkte vej til at initiere objektets værdier, men her vil objektet, i modsætning til ValiderInput, rejse en kørselsfejl (dvs. en "typen stemmer ikke overens"-fejl), hvis typen af input ikke er i overensstemmelse med den forventede værditype. ValiderInput vil blot vedligeholde en liste med fejltekster som kan aflæses (via egenskaben Valideringsfejl på objektet), som kan præsenteres for brugeren.

Når objektet gemmes (via kaldet til Gem-metoden), udføres forretningsvalideringen og hvis denne ikke går igennem, rejses der en kørselsfejl! Denne kørselsfejl kan fanges i en On Error Resume Next-sektion og valideringsfejlene kan derefter aflæses (som tidligere nævnt).

Mere seperation

Som det bliver indikeret i Gem-metoden, så opretter jeg et nyt objekt til at håndtere lagring af forretningsobjektets data. Dette gør jeg dels for at holde forretningslogik og databasetilgangslogik adskildt så det er lettere at skifte datalaget, dels for at holde en renere kode i mit forretningsobjekt så forretningsobjeket kun håndterer reelle forretningsregler.

Denne fremgangsmåde kan godt virke noget omstændig i ASP, men jeg tror det er besværet værd, hvis man sidder med større projekter og i teams med flere udviklere, som dels har forskellige kompetencer indenfor de enkelte niveauer af systemet, dels har større behov for at ændre i samme forretningsområder (på forskellige niveauer) samtidig.