Business rules: validate and filter data
By A.Bouchez on 2011, Wednesday June 1, 08:19 - SQLite3 Framework - Permalink
According to the n-Tier architecture, data filtering and validation should be implemented in the business logic, not in the User Interface.
If you were used to develop RAD database application using Delphi, you may have to change a bit your habits here. Data filtering and validation should be implemented not in the User Interface, but in pure Delphi code.
Data filtering is a process run on the User entry: for instance, it will
trim left or right spaces, make the text uppercase...
Data validating is performed before saving the data to the database: for
instance, an email address is checked for consistency, a field value to be
unique...
Some try to implement this using an external
scripting engine, in a procedure/event mode. Back to the 80th...
In our ORM framework, filtering and validation can be performed by creating
some Delphi classes, which may be used on both Server and Client side.
In order to make this easy, a dedicated set of classes are available in the
SynCommons.pas unit, and allow to define both filtering and
navigation.
They all will be children of any of two common ancestors,
named TSynValidate and TSynFilter classes:
TSQLRecordfield content validation is handled in the newTSQLRecord.Validatevirtual method, or via someTSQLValidateclasses;TSQLRecordfield content filtering is handled in the newTSQLRecord.Filtervirtual method, or via someTSQLFilterclasses.
Some "standard" classes are already defined in the SynCommons
and SQLite3Commons unit, to be used for most common usage:
You have powerful validation classes for IP Address, Email (with TLD+domain name), simple regex pattern, textual validation, strong password validation...
Note that some database-related filtering are existing, like
TSynValidateUniqueField which derivates from
TSynValidateRest. Thanks to this kind of data-driven classes, you
can filter or validate data using all methods of the ORM, in pure Delphi code,
with no SQL code to write by hand.
Of course, the SQLite3UIEdit unit now handles
TSQLRecord automated filtering (using TSQLFilter
classes) and validation (using one of the TSQLValidate
classes).
The unique field validation is now in TSQLRecord. Validate and
not in SQLite3UIEdit itself (to have a better multi-tier
architecture).
To initialize it, you can add some filters/validators to your
TSQLModel creation function:
function CreateFileModel(Owner: TSQLRest): TSQLModel;
var Classes: array[0..high(FileTabs)] of TSQLRecordClass;
i: integer;
begin
for i := 0 to high(FileTabs) do
Classes[i] := FileTabs[i].Table;
result := TSQLModel.Create(Classes,'synfile');
result.Owner := Owner;
result.SetActions(TypeInfo(TFileAction));
result.SetEvents(TypeInfo(TFileEvent));
TSQLFile.AddFilterOrValidate('Name',TSQLFilterLowerCase);
TSQLUser.AddFilterOrValidate('Email',TSQLValidateEmail);
end;
Calling AddFilterOrValidate method is enough to declare
the validation for the whole framework.
Feedback and comments are welcome in our forum.