Noop!

Why would anyone want a LinqSpec spec like this?

public static Specification<Foo> Noop()

{

   return new AdHocSpecification<Foo>(f => f != null);

}

 
 

Glad you asked! What if you were approaching a SpecificationBuilder like so:

public override Specification<Foo> BuildSpecs()

{

   var specBuilder = new SpecificationBuilder<Foo>();

   some if/then logic goes here for building up specs

   if (specBuilder.ToSpecification() == null)

      specBuilder.AddAnd(new AdHocSpecification<Program>(p => p != null));

   return specBuilder.ToSpecification();

}

 
 

Well, if you were doing this you might be wise. Why so? Because it would be disasterous to return a null specification. In such a scenario, you can expect an error when you try to use the specification. If you don't want to do any filtering then you should just have a filter that returns everything.

Is there a downside? Well, I'm glad you asked that question too. If you use the Noop spec with other specs, things break. Why? We haven't figured that out yet. We just see that we are getting NHibernate exceptions and are working to avoid using Noop in tandem with other specs. You pretty much need to craft a method like the one above in which you just slip in the Noop conditionally at the very end. One pain point of late came when we broke filtering into two separate chunks, one for security and one for user-driven filtering. We have found we can end up with a Noop for the security half of things and then append the Noop to the specification for the user-driven half of things. We are going to need to architect anew our approach.