Hi all
We've spend a considerable amount of time bringing a CSLA 3.8 project into the present with CSLA 4.5.
Our biggest challenge was the legacy rules, and while "converting" them is straight forward enough, it's a bit tedious and verbose (mostly for the small and simple ones).
PS: I'm aware of the hard work @JonnyBee has put into CSLA-Validation project to help with this special scenario of running legacy rules under CSLA 4's new rules system. Unfortunately, having to use special subclasses for our business objects made it a non-starter for us.
We found that we would regularly use the CSLA built-in Lambda rule for the convenient shorthand it offers on simplistic rules.
To make it even easier and more productive we created our own variation on the Lambda rule to make it a bit more flexible, compact and readable. Enter "QuickRule" ...
@JonnyBee / @Rocky - Feel free to adapt / use in framework, or just let me know if I should create a pull request for it if you want it in the framework.
With it you can write things like:
// Example 1. This sample creates and adds a lambda
rule (LogChangeRule)
// for the primary property PostCode
BusinessRules.AddRule( new QuickRule( LogChangeRule
).For( PostCodeProperty ) ); // Example 2. This sample creates and adds a lambda
rule (CheckIfExistsRule) // for the primary property PostCode, and uses it
as an input property BusinessRules.AddRule( new QuickRule( CheckIfExistsRule
).For( PostCodeProperty ).UsingIt() ); // Example 3. This sample creates and adds a lambda
rule (MutatePostCodeToUpperCase) // for the primary property PostCode (using the
PostCode as an "input property") // and affects the FormattedAddress property as a
consequence ("affected properties") BusinessRules.AddRule( new
QuickRule( MutatePostCodeToUpperCase ) .For( PostCodeProperty
).UsingIt() .Affects(
FormattedAddressProperty ) ); // Example 4. This sample creates and adds a Lambda
rule (MutateTotals) for the primary // property ProductCode and uses SellingPrice and
Quantity properties as input properties. // The LineTotal and Tax properties are affected by
the rule. BusinessRules.AddRule( new
QuickRule( MutateTotals ) .For( ProductCodeProperty
) .Using( SellingPriceProperty,
QuantityProperty ) .Affects(
LineTotalProperty, TaxProperty ) );
Please refer to the following gist for the implementation details.
https://gist.github.com/Jaans/d305de962638022b04e5
You are welcome to use and abuse as you see fit - just don't hold me liable ;-)
Hope that helps,
Jaans
I like the concept/idea and will look into this.
Maybe FluentRule or FluentLambdaRule is a better name than QuickRule to make the class name more self explaining.
Great! By all means - adapt and change as you need. We actually use the name FluentRule for ourselves. We add extension methods to it on a project by project basis for frequently used scenarios.
Given that this makes it quick and easy to manipulate the the input / affected properties, I'm finding that I have less need to create distinct classes for rules overall and it is quite productive for the frequently used / simplistic rules.
Copyright (c) Marimer LLC