Benefits of virtual properties and mapping methods

[ConvertFromOldNGs]

by Marcelle Goslin >> Tue, 30 Mar 2004 0:01:11 GMT

Hi All

Could anyone please outline any disadvantages to using virtual properties and mapping methods?

I have a situation where we are required to use business rules using a huge number of properties to classify our main business object into several classification buckets.

It seems an elegant solution to define a virtual property with a "get" mapping method per classification.
1) We don't have to keep calling an updating method to explicilty reset a non-virtual property every time one of the above mentioned properties changes (or sledgehammer approach, re-evaluate all classifications every time the BO is updated)
2) The business rules are precisely defined in the model without a lot of surrounding conditional logic

Would there be significant performance issues/overheads?

Most of our application is GUI, with limited batch

Thanks
Marcelle

[ConvertFromOldNGs]

by Rob B >> Thu, 1 Apr 2004 23:55:54 GMT

Advantages of a VP over a method is visibility to the method result in the inspector window, and availability to reportWriter, relational view, etc. They can also help orginise your code, as in your case by grouping business rules.

Whether to evaluate once and store the result, or evaluate on demand (using a VP) is a common design decision - the latter is usually preferred to minimise database size and activity, but only if the overhead of method execution at runtime is acceptable, which would depend on complexity of the algorithm and frequency of access.

Take care if your classification is an object, and your mapping method creates a new instance. When using virtual properties that aren't primitive types, if your mapping method creates and returns an object (this is particularly common with collections), then it's easy to forget the corresponding delete. Providing a method with an io parameter can be a better solution; the calling method must create the parameter, so it's more likely that the delete will not be forgotten, e.g.

1. Virtual allBlueBoxes property - the transient created by the mapping method hasn't been deleted.

foreach box in store.allBlueBoxes do
...
endforeach


2. Instead, assign the transient to local variable theseBoxes

theseBoxes := store.allBlueBoxes;
foreach box in theseBoxes do
...
endforeach
epilog
delete theseBoxes;


3. Alternatively, the getBlueBoxes method has an io parameter

create theseBoxes transient;
store.getBlueBoxes(theseBoxes);
foreach box in theseBoxes do
...
endforeach
...
epilog
delete theseBoxes;


Rob B

[ConvertFromOldNGs]

by Marcelle Goslin >> Fri, 2 Apr 2004 6:06:22 GMT

Thanks for your response.
I was afraid of going into VP overload, but you have largely laid my fears to rest.
Marcelle

[ConvertFromOldNGs]

by Patwos >> Tue, 6 Apr 2004 9:33:52 GMT

Rob,

I couldn't help but notice that you've fallen into a common mistake. In your example, you would be better to make the parameter "input" not "io" as I doubt you will ever want the variable referring to a different instance of theseBoxes - doing so would potentially cause the same transient leak you are trying to avoid....

Hope that helps,
Pat.

[ConvertFromOldNGs]

by Rob B >> Wed, 7 Apr 2004 23:26:16 GMT

Ah, a fine eye for detail ... thanks Pat