Aprill

Valideerimine atribuutidega

Marek Tihkan

Atribuutide kasutamine valideerimiseks tundub paljude jaoks hea mõte olevat. Seda väidet kinnitab selliste raamistikkude rohkesus. Ei saa vastu vaielda, et see on üks lihtsamaid viise, kuid tasuks ka vaadata alternatiive enne kasutamist, sest seegi pole ilma tumeda pooleta.

public class Person
{
    public int Id { get; private set; }

    [Required, Length(Max = 25)]
    public string FirstName { get; set; }

    [Required, Length(Max = 25)]
    public string LastName { get; set; }

    [Required, Pattern("[0-9]{11}")]
    public string PersonalCode { get; set; }

    [Required, PastDate]
    public DateTime DateOfBirth { get; set; }

    [Required, Between(Min = 1, Max = 120)]
    public int Age { get; set; }
}

Esimene muret tekitav koht on see, et klass Person on seotud konkreetse valideerimise raamistiku attribuutidega. Paljusid see ilmselt ei häiri. Kuna neid raamistikke on palju, siis raamistiku ümber vahetamine hiljem võib täiesti tõenäoline olla (kui algne valik ei olnud hea ja mõnel teisel raamistikul on paremad võimalused) ning palju õnne selle tegemisel.

Teine probleem seisneb selles, et kasutades mõne raamistiku äriklasse, siis ei ole võimalik neile valideerimise reegleid lisada. See tähendab seda, et luues väärtuse tüüpi (Value Object) klassid, mida mitmete süsteemide puhul kasutada saaks (Money, Quantity, GeographicBoundary jne), puuduvad valideerimise reeglid.

Kolmas probleem tekkib sellega, et äriloogikas on tihti keerukamad reeglid, mida atribuudid täita ei suuda ning seetõttu tuleb lisada näiteks Validate meetod juurde. See teeb klassi disaini imelikumaks.

Atribuutidega on võimalik ka häid asju korda saata. Näiteks võime Required atribuudiga elementidele lisada automaatselt andmebaasi loomise skripti NOT NULL märke FluentNHibernate abiga.

public class Persistence : PersistenceModel
{
    public Persistence()
    {
        Conventions.ForAttribute<RequiredAttribute>((attribute, property) =>
        {
            if (property.ParentIsRequired)
                property.SetAttribute("not-null", "true");
        });
    }
}

[MSDN Magazine: Conventions over configuration]

Sarnaselt võime luua TextBoxid, mille pikkus on paika pandud pikkuse reegli järgi või luua DropDownListi väärtustega, mis jäävad vastavasse vahemikku. Siinkohal tuleb ainult ideedel lennata lasta ja neid realiseerida.

Siiani oleme tegelenud ainult reeglite deklareerimisega, siis tuleks ka need mingil moel jõustada. Lahendus selleks on luua teenus IValidationService:

public interface IValidationService
{
    IValidationResults Validate<T>(T entity);
    IValidationResults Validate(Type entityType, object entity);
    IValidationResults Validate(object entity);
}

Seda võime kasutada enne salvestamist andmehoidlas või registreerida salvestamise eelseks sündmuseks, kus ebakorrektsete andmete puhul visatakse viga. Mõlema puhul oleks mõistlik ServiceLocatori käest konkreetne realiseering küsida ja käivitada mõni neist meetoditest. Siinkohal tasub silmas pidada ka seda, et NHibernate annab tagasi proxy klasse ning valideerimine võib seetõttu vahele jääda kui valideeritava objekti tüüpi kaasa ei anna.

Tagasi ärimudeli atribuutidega solkimise juurde tulles, siis alternatiivne lahendus oleks kasutada neid transpordi objektidel ning äriolemid realiseerida selliselt, et neid poleks võimalik ebakorrektsesse seisu viia.

Raamistikud:

.NET

Java