February 28, 2017 at 8:01 am #10042Sten-Erik BjörlingParticipant
Why I use object classes as managers of data?
When creating a object for Persons it contains a number of methods for data access and business logic. The method $ReadPersonData which is part of a internal verification process within the object can be changed without disrupting the wider logic. Getting the persons data through a DAM is different than getting the data through a SOAP or REST call. Both the parameters in and the resulting variables out of the object is not changed (support for “contractual programming”). This is a functionality that i do not see to be easy implementable in a table class.
By using a “data object” as a controller I also can utilise the approach of creating table class templates – the difference between using a table class template or using @definefromsqlclass is that the template approach has the 30% of the processing cost compared to $definefromsqlclass. Might not matter much in a fat client app but it can really add up in a web service or mobile app context.
I also tend to support the approach of “shallow lattice” in regard to object inheritance levels – I rather prefer to use “utility object methods” in the code since I regard that more than a few inheritance levels can complicate both programming and not the least debugging. This approach is also usable when wanting to keep down memory use – having a large-sized table class covering a lot of functionality will waste memory since close to all its functionalities are not usable at every instantiation – by “modularising” the needed code the memory footprint can be drastically smaller – especially important in the case of web service and mobile apps with a large number or users and parallel processes – it adds upp quickly. Imagine what happens with a system of 1000 active users each in their code execution keeping 20 instances of table classes of 20-50 kB. And then add all the other code…
Take care, all the best…
You must be logged in to reply to this topic.