The main idea for these structure was to separate the different areas of the program from each other so that they only knew what they need to know and I'm only passing/copy around the TData. And also that a programmer knows that if you add a new field to TData that you have to adapt the other two classes which do stuff with it. I also thought about using interfaces for that until I realized that this only works for functions...
@Martin_fr
I could also use a TRecord instead a class for the dataset. That would allow me to use the property as shown, right?
The TDatabaseRecord inherits from the base class of mORMot framework for saving to a database.
Yes... But...
If TData is a record, and you pass it around, then each (each field "FData" and each param "AData") is a separate copy.
Changes to one record, do not affect the other records.
- For params (function params) you could use "var" param, and that will pass a pointer to the original.
- But for fields, you can not do that. Of course you can make the field a pointer to a record, but then you again cannot use the forwarding property.....
So using records you may end up with a lot of work keeping your data in sync.
If Everything only works with TData, then why do the other classes need forward properties?
No external code should need to access TDataRecord.Id or TDataAccess.Id.
Any such external code should work with a TData?
Side note: Do all those classes need "published" fields? Do they use RTTI to access those fields?
While I still have no clue about TDataAccess, let me take a guess on TDataRecord.
Do you use some sort of ORM, and it has a baseclass for objects that can be stored in a table?
So TDataRecord is a wrapper around TData, in order to get a class that the ORM can store?
Then TDataRecord would need the published fields for the Orm, but TData would not.
The best way forward would then depend on what other means the ORM offers to deal with data.....