jump to navigation

Janga – A Validation Framework with a Fluent API September 26, 2010

Posted by ActiveEngine Sensei in .Net, ActiveEngine, Business Processes, C#, Design Patterns, Expression Trees, Fluent, LINQ, New Techniques, Problem Solving.
Tags: , , , , , ,
add a comment

Why can’t we  write code that read likes this:

bool passed = employee.Enforce()
                    .When("Age", Compares.IsGreaterThan, 45)
                    .When("Department", Compares.In, deptList)

One of the enduring challenges for software developers and business is to create abstractions that accurately represent concrete rules for business operations.  As opposed to operating like our tribal ancestors where you had to kill a goat, start a fire and listen to the blind boy tell the tale told for thousands of years, today we’d like to be able to read stories ourselves.  Hopefully the story that we read matches the reality of what we have implemented in our code.  Many nested if statements can quickly make verifying that the code matches the story very difficult.

A fluent validation API can assist with this.  Look at the code at the top of the post.  You can show that most people without having to get out the smelling salts.  For your fellow developers its creates a succinct way to express precisely what the logic is. They’ll love you for it.

Janga, a fluent validation framework for creating such an API.  There are three goals to be met here, and Janga fulfills these goals:

Goal 1 – Be able to chain “When” clauses together.  Each test – represented by the “When” clause – needs to chained together.

Goal 2 – Accept a test on any object property where the test criteria is defined in the form of x <= y at runtime.  The types of objects and their properties will not be known until runtime, so our framework must be able to analyze an object and construct a test against each property as it is presented.  This is NOT the specification pattern, where you define a delegates ahead of time.

Goal 3 –  Flexibly handle errors by either halting on the first error, or by proceeding with each test and logging each error as it is encountered.

The code Sensei will present here fulfills all of these goals and gives us the fluent magic we see in the sample at the top of this post.  Before we delve into the details, the sources for the ideas and explanations of Lambda Expressions, fluent apis, Expression trees,  should be acknowledged and applauded, because they got Sensei thinking along the right path:

Fluent Validation API

Roger Alsing – Fluent Argument Validation Specification

Raffaele Garofalo – How to write fluent interface with C# and Lambda.

Lambdas, Expression Trees, Delegates, Predicates

Expression Tree Basics – Charlie Calvert’s Community Blog

Marc Gravell – Code, code and more code.: Explaining Expression

Marc Gravell – Code, code and more code.: Express yourself

Implementing Dynamic Searching Using LINQ (check the section regarding dynamic expressions.)

Creating this api is a twisted cluster-wack of a zen puzzle.  The code for this solution consists of one class and three extension methods.  We’ll make use of generics, delegates and expression trees to evaluate our When clauses.  In the end we’ll see that with very little code we get a lot of mileage.  It took Sensei a long time to wrap his head around how to piece all of these things together, so hopefully the explanation will be clear.  Note that the solution has tests that demonstrate how to use the framework, so if you want to skip the madness and just try things out, go for it.

Goal 1:  Chaining When clauses together

To get the ball rolling, there is an extension method Ensure that will accept the object you wish to evaluate, encapsulate that object into a Validation class.

public static Validation<T> Enforce<T>(this T item, string argName,
    bool proceedOnFailure)
    return new Validation<T>(item, argName, proceedOnFailure);

Creating a chain of tests is accomplished with the Validation class and successive calls to the extension method When.  Validation encapsulates the object you wish to test.  In our examples that’s Employee.  Employee will be passed on to When, When executes a test and stores the results in Validation.  After the test, When returns Validation, and this creates the opportunity to execute another extension method.

public class Validation<T>

    public T Value { get; set; }
    public string ArgName { get; set; }
    public bool ProceedOnFailure { get; set; }
    public bool IsValid { get; set; }
    public IList<string> ErrorMessages { get; set; }

    public Validation(T value, string argName)


        this.ArgName = argName;
        this.Value = value;
        this.ProceedOnFailure = false;

        //  Set to valid in order to allow for different chaining of validations.
        //  Each validator will set value relative to failure or success.
        this.IsValid = true;
        this.ErrorMessages = new List<string>();


     public Validation(T value, string argName, bool proceedOnFailure)
        this.ArgName = argName;
        this.Value = value;
        this.ProceedOnFailure = proceedOnFailure;

        //  Set to valid in order to allow for different chaining of validations.
        //  Each validator will set value relative to failure or success.

        this.IsValid = true;
        this.ErrorMessages = new List<string>();

Signature of When (note that we return Validation):

public static Validation<T> When<T>(this Validation<T> item, string propertyName, Compare compareTo, object propertyValue)

Before we continue on with reviewing dynamic evaluation by the When clause, you could stop here and still have a useful mechanism for creating validation routines.  That is, you could create a extension method for each validation you want to perform.  One example could be:

public static Validation<Employee> LastNameContains(

        this Validation<Employee> employee, string compareValue)


    var result = employee.Value.LastName.Enforce("LastName",


    employee.IsValid = result.IsValid;



            .ForEach(x => employee.ErrorMessages.Add("LastName => " + x));

    return employee;


So instead of Ensure.When you will use Ensure.LastNameContains(“Smi”).  You will also have to create a new method for each condition.  This is still quite expressive and would go a long way to keeping things organized.  This would be more in the spirit of the specification pattern.

Goal 2:  Dynamically Evaluating Tests at Runtime

As stated, the “tests” are performed with extension method When.  When accepts the Validation object, along with propertyName and the propertyValue that you are testing.  The enum Compare determines the type of test to perform.  The comparisons are:

public enum Compare
    Equal = ExpressionType.Equal,
    NotEqual = ExpressionType.NotEqual,
    LessThan = ExpressionType.LessThan,
    GreaterThan = ExpressionType.GreaterThan,
    LessThanOrEqual = ExpressionType.LessThanOrEqual,
    GreaterThanOrEqual = ExpressionType.GreaterThanOrEqual,
    Contains = ExpressionType.TypeIs + 1,
    In = ExpressionType.TypeIs + 2

The magic of When stems from the use of Expression trees as delegates.  As defined on MSDN, an expression tree is:

Expression trees represent code in a tree-like data structure, where each node is an expression, for example, a method call or a binary operation such as x < y.

You can compile and run code represented by expression trees. This enables dynamic modification of executable code, the execution of LINQ queries in various databases, and the creation of dynamic queries.

This gives you the ability, at runtime, to dynamically evaluate an expression in the form of x = y, also referred to as a binary expression.  And in our case, we wish to evaluate:  Employee.Age = = 45.  The delegate takes care of presenting the type of the Expression and it’s components to the runtime engine.

Marc Gravell explains the difference between a delegate and an Expression as:

  • The delegate version (Func<int,int,bool>) is the belligerent manager; “I need you to give me a way to get from 2 integers to a bool; I don’t care how – when I’m ready, I’ll ask you – and you can tell me the answer”.
  • The expression version (Expr<Func<int,int,bool>>) is the dutiful analyst; “I need you to explain to me – if I gave you 2 integers, how would you go about giving me a bool?”
  • In standard programming, the managerial approach is optimal; the caller already knows how to do the job (i.e. has IL for the purpose). But the analytic approach is more flexible; the analyst reserves the right to simply follow the instructions “as is” (i.e. call Compile().Invoke(…)) – but with understanding comes power. Power to inspect the method followed; report on it; substitute portions; replace it completely with something demonstrably equivalent, etc…

.NET 3.5 allows us to create “evaluators” with Lambda Expressions compiled as delegates that will analyze an object type, the comparisons we can make, and the values we want to compare dynamically. It will then execute that tiny block of code. This is treating our code as a set of objects.  A graph representing this tree looks like so:

Each node on the tree is an Expression. Think of this as a “bucket” to hold a value, a property or an operation.  For the runtime engine to know what the type and parameters of the Expressions are, we create a delegate from the Lambda expression of that node.  In other words, we let the compiler know that we have an expression of type Employee and will evaluate whether Employee.Age is equal to 45.

To accomplish the magic at runtime, you need to set up “buckets” to hold Employee.Age or Employee.FirstName and their values with their respective type for evaluation.  Furthermore we want to be able to evaluate any type of binary expression, so our Expression will make use of generics and a tiny bit of reflection so that we will have code that “parses” the object and it’s properties dynamically.

The Extension Method When:

public static Validation<T> When<T>(this Validation<T>; item, string propertyName, Compare compareTo, object propertyValue)

Creating the delegate of the Lambda expression:

//  Determine type of parameter.  i.e. Employee
ParameterExpression parameter = Expression.Parameter(typeof(T), "x");

//  Property on the object  to compare to.  i.e. Employee.Age
Expression property = Expression.Property(parameter, propertyName);

//  The propertyValue to match.  i.e 45
Expression constant = Expression.Constant(propertyValue, propertyValue.GetType());

This takes care of the X and Y of the binary expression, but the next task is to create the comparison as an Expression as well:

Expression equality = CreateComparisonExpression<T>(property, compareTo, constant);

The type of comparison is determined by the enum Compare.  Once these steps are completed we convert the expression into a delegate with the statement:

var executeDelegate = predicate.Compile();

If you are worried about performance and the use of reflection, note that the use of static will greatly minimize this impact.  Basically you’ll take the performance hit on the first run but not on the subsequent runs.

Goal 3:  Error Reporting

For error reporting, Validation requires the name of the object with the property ArgName, and asks that you specify whether you wish to halt when there is an error.  This is accomplished with ProceedOnFailure.  An error log is created when you wish all tests to complete despite their respective results.  When you want to halt on the first error and throw an exception set the ProceedOnFailure to false.

Reporting the errors themselves takes place in each When clause, and this is implemented at the end of the When extension method.

//  Report Error handling
if(item.IsValid == false)
        item.ErrorMessages.Add("When " + item.ArgName + "."
            + propertyName + " " + compareTo.ToString()
            + " " + propertyValue + " failed.");
        throw new ArgumentException("When " + item.ArgName + "."
            + propertyName + " " + compareTo.ToString()
            + " " + propertyValue + " failed.");

Finally we need to return the Validation object so that we can chain another When operation

To recap, When is a dynamic filter where at runtime, code is evaluated and created on the fly to analyze and execute a tree representing code as an object.  The expression trees can be applied to any object and evaluate the object’s properties.  Holy snikes!!!  If that doesn’t scare you how ‘bout chaining When’s together by always returning a Validation object so that you continue to apply another extension method to it.  Twisted Zen mind torture indeed, since we have complicated looking code so that we can less complicated “business code”.

Here is the source code with unit tests.

The Economics of Protecting the Red Shirts July 29, 2009

Posted by ActiveEngine Sensei in .Net Development, ActiveEngine, Business Processes, Coaching, Design Patterns, Mythology, Personal Development, Problem Solving, software economics.
Tags: , , , , ,

Recently I came across this post from a fellow lamenting the lack of interest on the part of .Net developers in architecture solutions such as IoC, Dependency Injection, ORMs, and the like.  800px-KirkSlapsSelfThis stood out in stark contrast to Java developers who this person interviewed, who either were conversant with the technology or were interested enough to pursue informing themselves further.  Some call this the result of Drag -n -Drop design as laid out in a post  by Greg Young, a Microsoft MVP and .Net developer who has specialized in high performance applications.  Greg maintains in his post Java vs. .Net Developers that drag and drop is mis applied and there needs to be an greater effort the isolate the cases where it is mis used.  This practice has arisen, he maintains, from poor training and lack of awareness of other development platforms. (more…)

Now That’s an ActiveEngine – Agile Dissected and Skewered February 16, 2008

Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Design Patterns, Problem Solving.
Tags: , , ,

Head over to Bill Miller’s blog to read his great post on Agile on and applying the appropriate problem solving techniques to business processes. Bill very decisively lays out the case for NOT using Agile as a tool for solving problems; rather, you should use logic, analysis, and experience which can only be come with time. No shortcuts.

Bill is truly in possession of an ActiveEngine toolkit. Read his material, learn and enjoy.

Outsourcing Your ActiveEngine. January 28, 2008

Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Design Patterns, Problem Solving.
Tags: , ,

First of all, never, ever look for third party tools will magically implement your core, proprietary processes.  If your processes differentiate you from your competition, then by definition you will not find them boxed up in a software package.  You want an AR system, go buy one, as AR will no give competitive advantages as it just needs to function appropriately so you collect the bills.

The same holds true for your core capabilities.  Outsourcing programming activities to third parties can be like paying someone to train for a marathon for you.  Unless you have involvement and control of the development cycle you will never have a working product worth supporting.  Sure, you can find Open Source products that will perform functions for you but you still have to put them through a test cycle, and the same holds true for third parties.  You have to test them as rigorously as well.  In the end the success of this test will depend on your specifications and ability to communicate to potential partners in development.

This brings us to the subject of testability and verification.  If you are going to have a development outfit produce something, how will you inspect it?  What if they are not on site, how do you inspect then?  Should you be on a mission critical application you need to sit in on the team meetings everyday you can get a feel for what is driving the productivity of the project.  Many firms don’t like this, as it is disruptive to their processes but that’s their issue to resolve.  Maybe if they are too ridged to accommodate that they may not be the right development partner for you.  Finally, you should insist on the test team conducting their tests at your facility, with you at each step.  Again your goal is to get a feel for the issues that arise – maybe they relate back to the arguments that you were privy to earlier during the development phase.

If you come through this with a third party and produce a successful launch then you can consider relaxing some of the oversight, but not by much.  Proximity only breeds a higher degree of honesty.  It should be easier for you to get a feel for timing of solution delivery as you will have worked with team members and be familiar with strengths and weaknesses.  You may be in a position to request that a certain individual work on a project because of a good history of delivery.  Who knows, maybe that person even practices ActiveEngine methods.

5 Concepts in 4 Paragraphs with 3 Reasons 2 use 1 ActiveEngine Method January 26, 2008

Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Design Patterns, Problem Solving.
Tags: , , ,
add a comment

What is Sensei saying? With a title like that you should go to the next blog. NOOO!! This is a challenge to train your mind to use an ActiveEngine method. Why? Because you’ll find the productivity you’ll experience will be liberating. The ActiveEngine method is to state your objectives on 1 piece of paper, in English, with no acronyms, and read it everyday. It may seem underwhelming and obvious but it is rarely done. In the technical fields it is rarer, as quick and sharp thinks many times lack the discipline to keep things clear. So before we run out of paragraphs we better introduce the concepts otherwise Sensei won’t pull this stunt off. The big five are: streamlined communications, the theory of necessary and sufficient, the 80/20 rule, ignorance, and Cesar’s theory of the calm submissive mind.

Streamlining your communication is simple: turn off email except for two times a day, write emails less, and refer people back to your goals and elucidate your objectives and tactics in context of those goals. Probably you could use your one pager. Copy and paste works great with email, so you have to type less. For team projects publish the objectives EVERYWHERE. And, do not use acronyms. English.

The next three concepts – the theory of necessary and sufficient, the 80 / 20 rule, and ignorance – are related. Necessary and sufficient are those things that meet the conditions, only those conditions set forth in your objectives. the corollary questions are: Do you need it, and does it do what it should? A little wisdom will be needed if you are concerned with building software, as sometimes necessary and sufficient can paint you into a corner. But in many cases it will keep you out of the valley of constant re-working your solutions. The 80/20 rule, or Pareto’s Law, is the concept that only approximately 20% of any activity will produce 80% of your results. In other words, most of what we expend our energy on is not aligned with the productive acts that give you results. Both theories are enforced with that sheet of paper we talked about, as the activities you do should only be aligned with those goals. The one pager is the reference sheet for the ground rules regulating what you are working on, and in some cases how you do it. A state of “Ignorance” becomes applicable in that purposefully ignoring those actions, distractions, and musings that do not fall in the 20% category is a strength. If it ain’t on the sheet of paper, it don’t matter.

Finally, a calm submissive state of mind stems from discipline and consistency. Cesar Millan tames unruly dogs by walking them, everyday. This routine establishes order amongst the pack, and readies the dog to be formally trained. So, you need to”walk the project” and review those objectives, get the team members to recite them in their sleep. The benefits to these 5 concepts are clarity of thought, focused energy, and resolve. Imagine this: you bump into the CFO in lobby, and when asked what you are working on and your progress, you’ll have already practiced the answer with the clear, succinctly selected words your whole team has using to describe the project. They will also echo your summary. Your streamlined approach will instill confidence when your superior does not struggle to understand what it is you are describing. You’ll remain on task with the resolve to attain your goals. This will help you keep your job and advance. As promised, Sensei delivered the message: 5-4-3-2-1 you do it too.

TDD and Design Pattern Screencasts by Jean Paul Boodhoo December 21, 2007

Posted by ActiveEngine Sensei in .Net Development, ActiveEngine, Design Patterns, TDD, Test Driven Development.
Tags: , , , , ,

If you have read this blog, you’ll have noted that Jean Paul Boodhoo is a great resource to learn from. Below is a compilation of screencasts that he completed for DNR TV with Carl Franklin. You should take the time to review these, as you will see clearly that JP has dedicated himself to refining the art of programming. He himself freely admits that he has had to struggle to learn and develop his skills to the point where they are today. Watching him apply TDD with Resharper is utterly amazing.

You should take the time to view each of these and share them with your team members, as it will jump start your interest in enhancing your development discipline. Work on your core toolkit and improve your ActiveEngine!


Demystifying Design Patterns Part 1

Demystifying Design Patterns Part 2

Demystifying Design Patterns Part 3

Demystifying Design Patterns Part 4

Demystifying Design Patterns Part 5

The Clock is Ticking December 15, 2007

Posted by ActiveEngine Sensei in ActiveEngine, Coaching, Design Patterns, Mythology, Personal Development, Problem Solving.
Tags: , , ,
add a comment

The forth coming documentary movie Two Million Minutes discusses the changing demographics of our global economy:

Meanwhile, both India and China have made dramatic leaps in educating their middle classes – each comparable in size to the entire U.S. population. Compared to the U.S., China now produces eight times more scientists and engineers, while India puts out up to three times as many as the U.S. Additionally, given the affordability of their wages, China and India are now preferred destinations for increasing numbers of multinational high-tech corporations.

The premise of the documentary is that from 8th grade to high school graduation, student has 2 million minutes to prepare to enter the work force, be productive, fight the good fight to win the prize, bring home the bacon and contribute to society.

How do we as developers, architects, project managers spend our time? Some may contend that expansion of knowledge is the best route, that continual acquisition of skill is the key to remaining on top. The way of Bushido is to constantly refine through the repetition of basics. The life of Josh Waitzkin supports the latter theory, as neural pathways of the grand masters are created through analysis and repetition. Can this be done in 1 million minutes? What ways are we learning? What are the essential components to good design, and are they emphasized enough?

Design patterns come to mind as a kata, or set of instructions that when practiced to a high degree lead to increased performance. Design patterns describe quickly how a problem has been solved, and set expectations as to what is in store for you when you open up the code and read what has been done. When done correctly, design patterns will gain back some of those precious minutes.

But back to China and India. Are we, the software and architect community, too cloistered in our blogs and Alt.Net enclaves to contribute to the reduction of the 2 million minutes? Are we even a part of that 2 million minutes? Think about it.

ActiveEngine Sensei’s Mother Comes to Visit – Lessons in Design Patterns December 5, 2007

Posted by ActiveEngine Sensei in ActiveEngine, C#, Design Patterns, Mythology.
Tags: , ,
add a comment

For Thanksgiving Sensei’s mother came to visit the dojo, but this time she brought a new addition to the family, her dog. This puppy is lovable enough, and like all puppies needs training, which Sensei felt compelled to provide. When Sally got out of line and starting biting, Sensei held her down gently but firmly around the collar bone. This is an old trick that Cesar the Dog Whisperer practices with the smaller dogs – firm, gentle and consistent.

After two times, Sally stopped nipping at Sensei. “Wow, that really works quickly”, Sensei’s mother says.

“It’s easy to do, here’s how, ” and he showed her. The next time Sally started nipping, Sensei’s mother repeated the maneuver many times and lo and behold, Sally learned to not bite.

There are some lessons to be learned here for those who wish to practice Agile, Test Driven Development and implement design patterns: you must learn good technique from good practitioners, then repeat, repeat, repeat while seeking feedback. There’s no short cut to internalizing execution, and certainly no short cut to understanding when and why to apply design patterns. This begs the question for senior team members when do you make design decisions and what justification can you convey to junior team members concerning your choices?

Sometimes this can be very easy. The decorator pattern is a great example, as the justification answers the question of “I have many variations to accommodate in a billing process, and do not want a proliferation of classes or difficult logic to support all the exceptions.” To make this connection between technical implementation with business requirements takes practice, and the articulation of the justifications is a great way to obtain fluency. Repetition and review and those key ingredients that help create a powerful ActiveEngine toolkit.

%d bloggers like this: