Validation Block is really interesting. This idea (in various implementations) exists in some frameworks today, but I think that most projects implements there own validation pattern. The Validation Block gives you a good pattern for the validation or actually several patterns. You can validate in code (by using attributes) or configurations file. The difference between them are that using configuration you can change the validation rules after deployment by just changing the configuration file and in code you get a better encapsulation of the rules but you must re compile the code to do a rule change. I think that if you use configuration to specify the rules you can get problems getting an overview of all validations if you got a large system. The configuration file will be large and kind of messy (the buildin tool for maintaining configuration files will help you but not enough I think).
I think this Block will be useful for most validations in an average application. Try to use Validation Block for all validation and if you must you can use another pattern for the exceptions, when the Validation Block couldn’t help you. You can write you own validator classes and then use them as the build in validators.
I haven’t been able to write more complex validation rules yet I just spend some hours writing a test app to get a first opinion of this. First of all I think you should select one pattern for the validations. Don’t mix the specification of the validation rules in both configuration file and in code. If you mix this two you will get a cheezy mix of validation logic that will be hard to maintain.
Positive
- This is a good pattern for validations.
- Good to separate the validation code with business logic.
- Easy to use.
Negative
- It is more difficult to debug and track errors when using the Validation Block. I already got some problems when I didn’t get one rule to work. After a while it started to work without any changes made. Strange.
No comments:
Post a Comment