First Impressions Of Validation Application Block with DDD

I would highly recommend the Enterprise Library drill down webcasts:

http://blogs.msdn.com/tomholl/archive/2007/04/25/enterprise-library-3-0-drill-down-webcasts.aspx

I've just watched the validation application block one and it left me with a few questions:

Looks good but I'm not sure how valid it is in practice on proper domain model based development. In particular a few things worried me:

1. Primtive Validation - The view seems to be that the primitive validation with the application block will deal with most cases but I'm not sure this is true...I think I'll end up creating a lot of custom rules just as I do now.
2. Configuration Flexibility - The configuration flexbility might be useful in some cases, associate the rules to the domain objects in XML configuration where appropriate. However the video was slightly confusing on how they were advising we used this. David was saying start with attributes and then move to configuration based approach once your domain model was "set". Tom was saying use configuration if the rules are likely to be flexibile or you don't have the code that you want to apply to rules to. Personally I think Toms approach seemed more appropriate for the type of development I do.
3. Attributes v Configuration Files - The whole Ruleset approach seems to be a bit basic. It seems odd that rulesets are not considered the default, lots of companies are applying domain models/layers where that layer is written in C#/Java and the rules are written in those languages. Business rules engines are not the only way to do it and the offhand way it was discussed left me a little worried. In our project most of our domain objects do have some inbuilt states and the validation rules are based on the state so and I'm not sure Rulesets give us enough flexibility.
4. Self validation - Where its necessary you can put validation methods into the classes being validated. Evans deals with the issues with such an approach in pp 224 on his book, the obvious one being if you go down that path your domain objects will be full of rule code. To me a Specification based approach is far better and so I would imagine we'd be using CustomValidators instead.
5. Custom Validators - Getting more into Specification style approach. Your rules must derive from a supplied base class. These classes look quite like the implementation of our IDomainRule interface, all very simple. You also need to write an attribute, again its simple enough and if you don't use this approach you'd need to write your own code to ensure validation rules are applied.
6. Policy Injection App Block Integration - The example integrating the Policy Injection seemed to me to be resulting in very ugly code, attributes like that on every argument would not be nice at all. I like the declarative approach but having a one line call to something like this ArgumentValidation.ThrowIfOutsideRange(....) in the method would seem to me to be much nicer.
7. Integration Adapters - Interesting way to integrate your domain validation into the UI, it'll be interesting to see how it works in practice and whether its flexible enough for us.In particular I'm not sure how this will work with the ASP.NET proxy validates as you need to specify the RulesetName but in our case which ruleset to use depends on the context. Having said that this could prove very useful.

On the Ruleset point I added a topic to CodePlex about it so hopefully I'll get some feedback.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone