Handy fluent-like quick rule to speed up writing your light-weight rules

Handy fluent-like quick rule to speed up writing your light-weight rules

Old forum URL: forums.lhotka.net/forums/t/12652.aspx


Jaans posted on Friday, May 30, 2014

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" Cool...

@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

 

 

JonnyBee replied on Thursday, June 26, 2014

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. 

Jaans replied on Thursday, June 26, 2014

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