BorlandTalk.com

Goran Smith · Guest

Ho do you handle validation in BO, both at the property/field level
and at object level?
For field level I see 2 possible approaches which must be implemented
by the setter method:
- set a flag
- raise an exception
For object level: a function in the base class, overridden
by all decendents (Validate) which should be called every time
object validation must be performed. This function can return
false (signaling an error) or raise an exception.
What do you think?

sanmaotuo_33@yahoo.com · Guest

IMO: object level Using Visitor Patterm

1ã€Each BO Defined as Visited (IVisited)
2ã€Each BO's Operation(Include Validation) Defined as Visitor
(IVisitor)

For Example:

IVisited = interface
function Accept(const Visitor: IVisitor): Boolean;
end;

IVisitor = interface
function Visit(const Visited: IInterface): Boolean;
end;

IBO = interface(IVisited)
function GetOID: string;
procedure SetOID(const Value: string);
property OID: string read GetOID write SetOID;
......
end;

TBO = class(TInterfacedObject, IBO)
private
FOID: string;
......
protected
//IBO
function GetOID: string;
procedure SetOID(const Value: string);
......
//IVisited
function Accept(const Visitor: IInterface): Boolean;
public
......
end;

function TBO.Accept(const Visitor: IInterface): Boolean;
begin
Result := Visitor.Visit(Self);
end;

.......

TBOValidationVisitor = class(TInterfacedObject, IVisitor)
private
.......
protected
//IVisitor
function Visit(const Visited: IInterface): Boolean;
public
......
end;

function TBOValidationVisitor.Visit(const Visited: IInterface):
Boolean;
var
Obj: IBO;
begin
Visited.QueryInterface(IBO, Obj);
if Obj <> nil then
begin
//Validation BO
.....
Result := True( or False);
end;
end;

if You want to Validate BO You Just do it Like This:

Result := Accept(TBOValidationVisitor.Create);

Wish My Example Can Help You Smile

Andy Gibson · Guest

Goran Smith wrote:

Jim Cooper · Guest

Peter Morris [Droopy eyes · Guest

I would only throw an exception in a setter if an attempt was made to modify
a value that should be read only.

For everything else I would use a validation routine that returns a list of
errors. I usually display this error list at the bottom of the form
(updates automatically as the error lists changes), I disable the Save
button if there are any errors. As a finaly precaution the class will throw
an exception if you try to save it when it has errors.

Constraint: StartDate <= FinishDate

StartDate := Today - 365
FinishDate := StartDate + 1;

Oops, set the year wrong in my DateTimePicker!

StartDate := Today;

In the first implementation you would get an exception "StartDate cannot be
after FinishDate" and will then have to change the FinishDate first (imagine
having to code checks like this when changing dates in code!), the second
implementation will let you change anything you like in whatever order you
choose, but only throw an exception at the point you try to save.

--
Pete
====
Audio compression components, DIB graphics controls, ECO extensions,
FastStrings
http://www.droopyeyes.com

My blog
http://blogs.slcdug.org/petermorris/

Jim Cooper · Guest

Hechicero · Guest

Hi,
From my point of view you can use different types of validations:
a) in the setter method if that property isnt related to any other
propertys (to avoid order conflicts) and the validation is simple and quite
obvious (for instance an integer property shouldnt be 45 for some reason)
b) in a method of the object (ej validate). Maybe a BOBase could contain
a virtual validate method.
c) Be aware thare can be different types of validations. the Ones usually
that ocurr during a process, the ones that you have to do before the object
is persisted to de DB, etc
But maybe there is a more complex case

e) at the end of a transaction where many objects participate. this is
more complex and sometimes a validation method is not enough. Maybe you
coud have a mediator perform the validations or a rulesEngine that takes the
collection of objects as an imput and validate them using a collection of
rules. (useful if rules changes frecuently and you dont want to recompile
each time a rule changes)

If you use an OPF The dupplication of validations in objects and database
constraints is something to bear in mind. (manintenance between DB
constrains and objects validations)

Esteban Calabria

Peter Morris [Droopy eyes · Guest

Joanna Carter [TeamB] · Guest

"Goran Smith" <goran (AT) forgetit (DOT) com> a écrit dans le message de news:
g9t832tbn3vlt549ehmq4a39kq2bvvub9b (AT) 4ax (DOT) com...

| For field level I see 2 possible approaches which must be implemented
| by the setter method:
| - set a flag
| - raise an exception

Neither :-)

I have used the idea of passing a null error argument object to the
validation routine, by reference, and then, if the object comes back not
null, I add the object to a list of errors in the business object. This list
can then be inspected at either storage time for objects populated in code
or when trying to exit a control for objects populated in a form.

| For object level: a function in the base class, overridden
| by all decendents (Validate) which should be called every time
| object validation must be performed. This function can return
| false (signaling an error) or raise an exception.

IMO, the only time that object validation is required is just prior to
storage. The above system allows for this.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

Jim Cooper · Guest

Peter Morris [Droopy eyes · Guest

Jim Cooper · Guest

Goran Smith · Guest

Goran Smith · Guest

Andy Gibson <delphi_pa (AT) hotmail (DOT) com> wrote:

Goran Smith · Guest