Παρασκευή, Μαρτίου 18, 2005

Should I redesign?

Recently, I re-read the excellent bdn article about dynamic Midas constraints and I remembered how much impressed I was about this capability of Datasnap. You can build a really thin client and don't even have to redeploy your client application and constraints can be altered as necessary.
What I've been thinking though is that the way KT Data Components are designed is contradicting to Midas philosophy. Forming (or manually copying) referential constraints in client side somehow spoils multi-tier theory (that is business rules and constraints should be defined on application server and simply be fetched to client).
Redesigning my components is of course an option. I could do this (although not easy) by defining a primary key collection property of a TKTDataSetProvider (representing Provider.Dataset primary key for each dataset that is included in the nested dataset structure that Provider forms) and a foreign key collection (from persistent fields belonging to the remote datamodule) for each primary key (possibly with a treeview like property editor).
I could then override Cds.GetRecords somehow to include these properties and this way enforce referential constraints in client side without having to manually redefine them. Of course, I should redesign Cds.ForeignKeys property so that it is not based on TField.Name, but TField.FieldName (finding a way to qualify FieldNames so that they are unique)
This is indeed very complex and in many aspects seems a better approach to design and implement from scratch, than trying to modify current implementation.
On the other hand, I don't know if referential integrity constraints alter so often (related for example to a check constraint e.g. "Salary>12000 and Salary<35000". A change in referential integrity constraints of a database more often represents a radical change in whole application design and that means that chances are that the client application would also have to re-build.
Besides, only TField.CustomConstraint properties are included in datapackets. In practice (and as far as I know), record level constraints should also be manually defined in client side (through Cds.Constraints propery).
Taking all these in account, may be leaving the implementation of my components as is should probably be enough. I don't know though (I repeat I don't have much experience to judge correctly) which aprroach is best. If anyone using my components has any suggestion, or comment, I certainly would like to have some kind of feedback