Hello,
I was wondering what do you guys normally do when you have a property that requires a very specialized rule. The type of rule that is so limited in use to a particular property the chances that you would be able to reuse that same rule for a different property are basically none.
My thoughts right now are to go ahead and create my own class that inherits from "IBusinessRule" and leave the "PrimaryProperty" as read-only. This way, I can hardcode the "PrimaryProperty" value inside the rule therefore formalizing the fact that such rule was only intended to be used by that one property.
But I wonder if others have run into similar issues and curious about how you guys dealth with the "problem". Perhaps I am going overboard with this? A simple comment on the rule may suffice..... but then again, maybe there is a better way.
Just curious,
Thanks.
Hi,
I would typically create that rule as an inner class, in the BO class. That way it's not reusable and the rule will also have access to inner variables in the BO.
When I have rules f.ex on lazy loaded properties I put them inside the BO class so the rule can have access to FieldManager and check if the field has been loaded or not.
I'd allow the rule to inherit from BusinessRule or ProperyRule - and you could even set the PrimaryPropery as an hardcoded IPropertyInfo (rather than use a parameter to the constructor).
Thanks Jonny,
What you describe is exactly what I am currently doing and yet, for some reason I still feel the need to take it one step further.
I don’t know, I guess that even as a private inner class I still feel that the CSLA is missing that business rule class people could inherit from that screams “hey! I am a single property rule”.
In any event, the current implementation of “IBusinessRule” exposes two public List<IPropertyInfo> properties (InputProperties and AffectedProperties). Since there is no way to make these properties read-only lists (to prevent modifications to the children), there is no way to create a truly sealed business rule class that can’t be misused even internally.
I think I may be trying too bee to much of a purist here. Thanks for the feedback though, is good to know I am not the only one that has arrived to the same solution.
Thanks.
I find it hard for anyone to try and reuse this type of rule:
BusinessRules.AddRule(new ValidToMustBeLessThanOrEqualToday());
}
public class ValidToMustBeLessThanOrEqualToday : BusinessRule
{
public ValidToMustBeLessThanOrEqualToday() : base(ValidToProperty)
{
InputProperties = new List<IPropertyInfo>{ValidToProperty};
}
protected override void Execute(RuleContext context)
{
var value = (IComparable)context.InputPropertyValues[ValidToProperty];
if(value.CompareTo(new SmartDate(DateTime.Today)) >= 0)
context.AddErrorResult(string.Format("{0} must be earlier ot today", ValidToProperty.FriendlyName));
}
}
Correct, you could even make the business rule private to secure it even more.
But perhaps I should have been clearer in my post. My beef wasn’t necessarily about preventing a developer from misusing the rule since a simple comment on the rule would make any developer aware of the purpose of the rule.
My issue had more to do with wanting to formalize the intent of the code through the code itself, and nothing would define the intent of a business rule designed for a single property than having the rule inherit from some specially designed "SinglePropertyRule" base class or something like that..... at least I think so.
Anyway, I am splitting hairs here. I just wanted to make sure I was on the same page (using best practices) as what other folks are doing.
Thanks again.
Yes, I absolutely recommend "sandwich"/intermediate base classes for both rules and business objects.
Myself, I use
and could probably have more types too.
By my definition - LookupRules should only run when user edits a field in UI.
Copyright (c) Marimer LLC