Toch zou je juist dan je datamodules als business objects moeten zien. Je hebt een object klant en een object order. De objecten zijn zelf verantwoordelijk voor het uitvoeren van de business rules: waar moet de data aan voldoen, wanneer mag een regel worden verwijderd...enz.
De betreffende klant is in dit geval een eigenschap van de order en wordt dus bij de order opgeslagen. Nadat de klant is ingevoerd en gevalideerd door het klant object kan zijn ID worden ingevuld bij een order. In principe hoeft het orderobject niets meer met de klant te doen, die is tenslotte al gevalideerd. Tenzij een klant aan specifieke regels moet voldoen voordat hij een order kan plaatsen. De regel die je dan hanteerd is dat de eigenschappen van de klant komen, maar de controle bij de order.
Dat wordt wat vaag, dus laat ik een voorbeeld geven. Bij een klant zijn altijd de volgende gegevens verplicht: Naam, Adres, Postcode, Woonplaats. Pas als een klant daadwerkelijk een order wil plaatsen moeten we over zijn KVK nummer beschikken. De validatie van klant ziet er dan als volgt uit:
Code:
if Naam.IsNull then
raise Exception.Create('Een vriendelijke melding');
if Adres.IsNull then
raise Exception.Create('Een vriendelijke melding');
enz..
Er mag best een klant worden opgeslagen zonder KVK nummer, daar gaan we dus nog niet op controleren. Als er een order wordt geplaatst wordt het een ander verhaal, dan moet er bij de klant meer worden ingevuld. In de validatie van de ordergegevens zou dan komen staan:
Code:
if not VarIsEmpty(KlantID.NewValue) then
begin
Klant := TKlant.Create(self);
try
Klant.FindID(KlantID.NewValue);
if Klant.KVKNummer.IsNull then
raise Exception('KVK nummer klant is nog niet bekend');
finally
Klant.Free;
end;
Dus: het zoeken van de klant en het retourneren van een KVKNummer is een verantwoordelijkheid van het Klant object het geven van een foutmelding is een verantwoordelijkheid van het Order object.
Ruben: om op je eerste punt terug te komen (zoekscherm), dat is een kwestie van user-interface en moet dus helemaal los staan van de object implementatie. Als je je business objecten schrijft zoals in dit voorbeeld maakt het niet uit hoe de gebruiker uiteindelijk een order en een klant koppelt het effect is hetzelfde: de business rules worden uitgevoerd. Misschien geef je je gebruiker wel beide mogelijkheden, als de opslag uiteindelijk maar op één plaats gebeurt. Het business object voert dan de regels uit en slaat de data op in de database.
Maakt dit iets duidelijker??
Bookmarks