[ALG] Waar validatie plaatsen

[Verwijderd]

Hallo,

in mijn titel staat wel algemeen, maar ik gebruik het op dit moment in PHP.
Ik ben bezig om mijn website te verdelen in lagen.

Alleen nu loop ik tegen een klein probleempje aan. Ik heb bijvoorbeeld een "Topic-object" dat maak van de postback van een pagina.
Dit object wordt verwerk door een data access object, die het moet wegschrijven in de database.

Alleen nu moeten er een aantal waardes moeten worden gevalideerd. Bijvoorbeeld numerieke waardes (omdat dat nog niet in php 4 is af te dwingen), maar ook string samenstellingen, bijv een email adres ofzo.

Ik wil in het formulier alle fouten weergeven (van de waardes die zijn ingevoerd). Maar waar kan ik dit het beste laten checken?
Ik kan er voor kiezen om na het vullen van het object meteen een validatie te doen op de waardes.
Maar ik kan ook het object naar het data acessobject sturen en daar in de methode van het weg laten schrijven daar de validatie er op los te laten.

Bij punt 1 weet je al meteen of het goed of fout is en werk je altijd met goede data.
Bij punt 2 is het voordeel dat je zeker weet dat waardes worden gecheckt voordat ze wordne weggeschreven.

Wat is jullie mening hier over?
Alvast bedankt

[whoami]

IMO check je best op de presentatie-laag of alle nodige velden in gevuld zijn.

Verdere validatie ( bv. een bepaalde kredietlijn die niet mag overschreden worden) doe je in de business - laag.
Als je dan een record insert, en het blijkt dat er bepaalde verplichte velden niet aanwezig zijn, of dat er aan bepaalde constraints niet voldaan is, dan is dat een exceptie, en kan je je DAL een exceptie laten gooien.

IMO kan je je validatie dus op verschillende plekken doen. Als de validatie op de ene laag omzeild wordt, heb je nog altijd een bijkomende validatie.

[ Voor 17% gewijzigd door whoami op 18-06-2004 15:38 ]

[Freee!!]

Normaal gesproken is het het handigste om validatie zo snel mogelijk (na ingave) te doen.

[bigbeng]

Ik persoonlijk vind dat je in elk geval moet valideren aan de serverkant in het business object. Immers, dit is verantwoordelijk voor bewaking van de semantische eigenschappen van object of programmatuur. Aan de clientside zet ik over het algemeen maar een beperkte controle neer, meestal voor het invoeren van verplichte velden en formatting van standaardvelden als e-mail of datum.

Je mag echter nooit client-side informatie klakkeloos vertrouwen! Ik verbaas me er steeds weer over hoeveel van mijn collega's dus wel client informatie direct doorsluizen naar de database.

[djluc]

Je hebt het hier over validatie, ik denk dat je dit eerst eens een beetje opm moet splitsen:
In je DAL controleer je of je input wel degelijk een integer is als deze verwacht wordt in de database. In je business layer controleer je of een emailadres wel degelijk aan bepaalde eisen(het @ enzovoorts) voldoet.

[Verwijderd]

bigbeng schreef op 18 juni 2004 @ 15:42:
Je mag echter nooit client-side informatie klakkeloos vertrouwen! Ik verbaas me er steeds weer over hoeveel van mijn collega's dus wel client informatie direct doorsluizen naar de database.

Inderdaad. De client kan tamelijk eenvoudig jou mooi geconstrueerde Javascript of wat voor checks ook veranderen. Clientside gebruik je uitsluitend vanwege het gemak voor de gebruiker: directe input validatie zondeer roundtrip. Daarna check je aan de serverside of er *echt* wel sprake is van goede input

tip: kijk ook eens naar [google=sql injection]

[Verwijderd]

Voor check heb ik javascript validatie om clientsite te valideren, maar ook serversite in php zelf. Omdat javascript validatie nogal makkelijk te omzeilen is of simpel weg uit te zetten.

Maar zoals jullie zeggen:
In de DAL type checking, stop ik werkelijk een int en een int en zijn alle waarde verplicht
In he BO checking op de inhoud, is de string die ik invoer een email adres.

Waar ik nu aan zit te denken is, is dat ik ook in de setMethode van het BO kan ik al een groot deel van de validaties afvangen. Hier in kan ik dan meteen checken of waardes numeriek zijn. Zodat in bijv aantal niet "Bojo" kan staan.

Dit laat voor de DAL alleen controle op verplichte velden.
Maar dat is ook informatie die ik eigenlijk ook van te voren wil hebben. Vooral in javascript, als waardes niet zijn ingevuld, geen postback

[djluc]

Verwijderd schreef op 18 juni 2004 @ 16:01:Dit laat voor de DAL alleen controle op verplichte velden.
Maar dat is ook informatie die ik eigenlijk ook van te voren wil hebben. Vooral in javascript, als waardes niet zijn ingevuld, geen postback

Als een veld niet in je database gedefinieërd is als NOT NULL is het niet verplicht imo. Daar kun je dus vrij eenvoudig op checken als je wilt. Maar imo moet je eigenlijk een standaard systeem hebben om je forms te genereren waardoor je al deze controlefuncties kunt standaardiseren.

[kasper_vk]

Volgens mij moet dat eigelijk op 3 plaatsen doen:

1. (server-side)Zover als mogelijk in je database (constaint e.d.), omdat je database, onafhankelijk van de toepassing(en) z'n eigen integriteit hoort te bewaken
2. (server-side)Tussen je applicatie en je buisiness-laag in, zie bigbang's post
3. (client-side)Om de gebruiker snel op fouten te wijzen en onnodige wachttijden en serverbelasting te voorkomen

Het gevolg is helaas dat je dus redundant bezig bent, maar 't is volgens mij de enige echt juiste aanpak. Overigens schijn je 2 en 3 samen te kunnen realiseren d.m.v. het gebruik van frameworks, zoals het Jakarta Validator framework, geloof ik.

[ Voor 9% gewijzigd door kasper_vk op 18-06-2004 17:23 ]

[kasper_vk]

Mr. Liu schreef op 18 juni 2004 @ 15:37:
Normaal gesproken is het het handigste om validatie zo snel mogelijk (na ingave) te doen.

Dit is trouwens een heel goeie opmerking, mits je je realiseerd dat je bij een 3-tier applicatie dus 3x gegevens invoert, namelijk van laag naar laag, totaan de DB.

Het overslaan van validaties tussen die lagen, betekend eigelijk dat een sterke koppeling realiseert tussen die lagen, omdat je 'vertrouwt' op de diensten (de validaties in dit geval) van een andere laag. Vaak is zo'n koppeling van de verschilende lagen ongewenst.