0

I am adding a "rounding" business rule to round a decimal property value to the number of decimal places specified in a separate integer property. This works nicely if both properties are members of the business object in question. As in the following VB.Net code...

BusinessRules.AddRule(New Round(_decimalProperty, _precisionProperty))

I have a private Round class that inherits from CommonBusinessRule and its constructor is as follows:

Public Sub New(decimalProperty As IPropertyInfo, precisionProperty As IPropertyInfo)
    MyBase.New(decimalProperty)

    InputProperties = New List(Of IPropertyInfo)()
    InputProperites.Add(decimalProperty)
    InputProperties.Add(precisionProperty)
End Sub

This triggers the rule Execute whenever either property changes, and the Execute code rounds just exactly like I want.

The Problem: I now have a situation where the precisionProperty is a property of the Parent business object. When the CSLA method for adding Business Rules for the Child Business Object is called, the Parent member of the Child Business Object is null, so I can't get to a reference of the parent's property. Is there any point in time AFTER the Parent field is no longer null, that I am allowed to add a new Business Rule? If so in what method? Is there another approach?

We have looked into passing down a reference to the parent business object (via constructors) to the child, but have decided against this approach for now (the child is actually 6 levels deep, and it appears this would require rework of our code generation schemes).

e-holder
  • 1,504
  • 4
  • 20
  • 33

1 Answers1

1

The parent property in the BusinessBase is generally used by the BusinessListBase to keep a relationship with its children. The parent property really isn't(shouldn't be?) used outside of that.

When I have a parent object with a property that affects child objects, I put the rule in the parent object that will then invoke any rules on the child object. You can pass in any values you like, even to the point of having a copy of the property on the child and just setting that as the parent property changes.

Kelly Ethridge
  • 1,669
  • 1
  • 11
  • 12
  • Thanks for the reponse, Kelly. We had come to a similar solution that involved a "copy" of the parent property that we kept synchronized on the child via EventAggregator mechanisms. If I understand, you are saying you can keep it synchronized by passing the value down to the child when the rules are invoked on the child. I hope to try this out and see if it is cleaner than the workaround we are currently using. Thanks again! – e-holder Aug 07 '12 at 20:13
  • We finally settled on a direct sync mechanism instead of an EventAggregator mechanism. Whenever the dependent property in the parent changes, we set the surrogate property in the children directly. To allow this, the surrogate property is made "internal" (or "Friend" in VB). Since the surrogate property is a dependency in the child business rule, there is no need for the parent to run rules on the child, the child rule fires automatically whenever the precision in the parent changes. – e-holder Aug 14 '12 at 21:31
  • I think the second part of your answer is fine, but I don't think there's any reason to avoid the Parent property. I've defined a property which basically just returns the parent cast to its appropriate type. – Andy Feb 12 '13 at 02:37