Making a property value cascade through a hierarchy

  • Thread starter Thread starter hawbsys
  • Start date Start date
H

hawbsys

I'm wondering what the best way to make a property value cascade down
through a hierarchy would be. Say
you have a MileageRate property which is always set at a default rate
at the Application level. But there is the option to override the top
level rate with a rate specific to a customer type. And so on down the
hierarchy.

Application
-> CustomerType
-> Customer
-> Project

Is there a neat way to do this? I have been playing with classes &
properties per the below:

Public Class Customer
Private _MileageRate As Nullable(Of Single)
Public Property MileageRate() As Nullable(Of Single)
Get
If _MileageRate.HasValue Then
Return _MileageRate
Else
Return Me.CustomerType.MileageRate
End If
End Get
Set(ByVal value As Nullable(Of Single))
if value.HasValue then
_MileageRate = value
End If
End Set
End Property

[...]
End Class

But I'm not sure this is the neatest way forward. For one thing it
doesn't databind smoothly, since a customer with no particular
MileageRate will have his MileageRate set to match the cascaded down
value as soon as you bind the MileageRate property to a textbox on a
form. Which isn't desirable because thereafter, if the Application
MileageRate is modified, he will still be set to the original value.
It will look like an intentional override.

There must be slicker ways of doing it.

Hawbsl
 
You could have a separate property of the Customer which indicates that they
use a custom rate instead of the default rate. This might be readonly and
set in one of the constructors if the customer status can never change, or
it could be read/write if the status can change. Use the value of the status
property in the rate property processing to determine the current value of
the rate.

However, that code assumes that the global Me.CustomerType.MileageRate is
always available. Generally, it is preferable to avoid this sort of
dependency in a class that might be re-used elsewhere. You could avoid that
by saving the default rate as the customer's rate and always returning the
saved rate as the property get. This would require a process to ensure that
the customer is up to date with the default rate, and the simplest way to do
that would be to include the current rate in a class constructor. Routines
that maintain a value for Me.CustomerType.MileageRate could user a
constructor that includes it - others would use a simple constructor that
did not change the current value.
 
You could have a separate property of the Customer which indicates that they
use a custom rate instead of the default rate. This might be readonly and
set in one of the constructors if the customer status can never change, or
it could be read/write if the status can change. Use the value of the status
property in the rate property processing to determine the current value of
the rate.

However, that code assumes that the global Me.CustomerType.MileageRate is
always available. Generally, it is preferable to avoid this sort of
dependency in a class that might be re-used elsewhere. You could avoid that
by saving the default rate as the customer's rate and always returning the
saved rate as the property get. This would require a process to ensure that
the customer is up to date with the default rate, and the simplest way to do
that would be to include the current rate in a class constructor. Routines
that maintain a value for Me.CustomerType.MileageRate could user a
constructor that includes it - others would use a simple constructor that
did not change the current value.
 
You could have a separate property of the Customer which indicates that they
use a custom rate instead of the default rate.  This might be readonly and
set in one of the constructors if the customer status can never change, or
it could be read/write if the status can change. Use the value of the status
property in the rate property processing to determine the  current value of
the rate.
Click to expand...

Thanks James, some useful ideas there.

Hawb
 
You could have a separate property of the Customer which indicates that they
use a custom rate instead of the default rate.  This might be readonly and
set in one of the constructors if the customer status can never change, or
it could be read/write if the status can change. Use the value of the status
property in the rate property processing to determine the  current value of
the rate.
Click to expand...

Thanks James, some useful ideas there.

Hawb
 
Back
Top