What would you use for a business validation layer?

Question

In my project I need to create a business object validation layer that will take my object and run it against a set of rules and return either pass or fail and it's list of failure reasons. I know there are quite a few options out there for accomplishing this.

From Microsoft:

• Enterprise Library Validation Application Block
• Windows Workflow Foundation Rules Engine

Open Source:

• Drools.NET
• Simple Rule Engine(SRE)
• NxBRE

Has anyone had any particularly great successes or failures with any of these technologies (or any that I didn't list) or any opinions on what they feel is best suited for business rules validation.

Edit: I'm not just asking about generic validations string length < 200, zip code is 5 digits or 5+4 but assume that the rules engine would actually be leveraged.

Answer 1

The code-versus-rules-engine decision is a matter of trade-offs, IMHO. A few examples are:

Advantages of code

• Potentially higher performance.
• Uses developers' existing skills.
• No need for separate tools, run-time engines, etc.

Advantages of rule engine

(Features vary across the various rule engines.)

• Rule DSL that is writable (or at least readable) by business users.
• Effective- and expiration-date properties that allow automatic scheduling of rules.
• Flexible reporting from rule repository supports improved analysis and auditing of system behavior.
• Just as data-base engines isolate data content/relationship issues from the rest of the system, rules engines isolate validation and policy from the remainder of the system.

Answer 2

A modified version of the CSLA framework rules.

Many of the other rules engines have the promise that goes like "The end user can modify the rules to fit their needs."

Bahh. Very few users are going to learn the complexities of the rules document format or be able to understand the complexities and ramifications of their changes.

The other promise is you can change the rules without having to change the code. I say so what? Changing a rule even as simple as "this field must not be blank" can have a very negative impact on the application. If those fields where previously allowed to be blank you now have a bunch of invalid data in the data store. Plus modern applications are either web based or distributed/updated via technologies like click=once. So you updating a couple of components is just as easy as updating a rules file.

So, because the developer is going to modify them anyway and because they are core to the Business objects operations just locate them in one place and use the power of modern languages and frameworks.

Answer 3

I didn't really like rule and validation blocks provided by Microsoft (too complex and inflexible) so I had to build mine, based on experience with custom business workflow engines.

After a couple of iterations the project has finally gone Open Source now (BSD license) and has proven helpful in production systems. Primary features of .NET Application Block for Validation and Business Rules:

• Simple to get started with
• Rules for the domain objects
• Rule Reusability
• Predefined Validation Rules
• Behavior Extensibility
• Proper object nesting
• Designed for DDD and UI level validation
• Multiple reporting levels
• Production-proof and active development
• Small codebase
• Open Source

Here's how a simple binding of rules at the UI level looks like:

Note, that current implementation does not have any DSL at the moment. C# syntax is expressive enough on its own, so there has been no demand to add Boo-based DSL on top.

Answer 4

I have to admit, for really simple validations, I tend to write my own very small, compact rules engine, mostly because I think using someone else's implementation just isn't worth it for a small project.

Answer 5

I've experimented with Workflow Foundation, used EntLib, and written my own rules engine.

In small applications where I only really need to do UI-based validation to ensure invalid data doesn't sneak into the DB, I reach for the EntLib Validation Block. It's easy to use and requires only a minimal amount of code in my domain objects, plus it doesn't mess up NHibernate or anything else in my technology stack.

For complex stuff, domain-layer validation, etc., I'd easily opt to write my own rules engine again. I'd much rather write rules in code, each rule in it's own tiny class, easily testable and very simple to compose complex sets of rules with.

In the large app that I worked on where I wrote this sort of rules engine, we then used FitNesse to test our rule configurations. It was great having that kind of tool to utilize to ensure correctness. We could feed it tables and tables of data and know, with certainty, that our configured rules worked.

Answer 6

If you are interested in rolling your own, read JP Boodhoo's post on Rules processing. Essentially he lays out a straight forward framework for validating domain objects.

Validatiion in the Domain Layer

Validation in the Domain Layer 2

Answer 7

Try

http://rulesengine.codeplex.com

It's lightweight, uses fluent-interfaces to define validation logic, extensible, and Free! You can even define rules on interfaces, implementors inherit the rules.

No more annoying attribute-style validation - what it you don't own the class you want to valida

It has a plug-in to Asp.Net MVC (server-side only).

There is also another project called Polymod.Net which uses RulesEngine to provide self-validating UI's as shown in the screen-shot!

Answer 8

Enterprise Library Validation Block provides a very AOP like approach and keeps things simple in both 3.1 and 4.1 from my experience.

Answer 9

I recommend using CSLA Framework. Not only for Validation but for other features also.