Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum

CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Handy fluent-like quick rule to speed up writing your light-weight rules

    This post has 2 Replies | 2 Followers

    Top 25 Contributor
    Posts 204
    Jaans Yes [Y] Posted: Fri, May 30 2014 8:08 AM

    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")


        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.


        new QuickRule( MutateTotals )

        .For( ProductCodeProperty )

        .Using( SellingPriceProperty, QuantityProperty )

        .Affects( LineTotalProperty, TaxProperty ) );



    Please refer to the following gist for the implementation details.


    You are welcome to use and abuse as you see fit - just don't hold me liable ;-) 

    Hope that helps,




    Top 10 Contributor
    Posts 2,279
    JonnyBee replied on Thu, Jun 26 2014 5:18 AM

    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. 

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 25 Contributor
    Posts 204
    Jaans replied on Thu, Jun 26 2014 6:05 AM

    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. 

    Page 1 of 1 (3 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems