views:

308

answers:

2

Hi,

Has anyone used the validation application block from enterprise library? Any success?

Anyways, my question is with regards to validating a numeric unique identifier. Lets say I have a Product class, with a ProductId property representing the unique identifier of the product. It is numeric. This identifier cannot be less than 1, it has to be greater than 1. I do not what validation type to choose using the validation application block. I was thinking of trying the range type, but it requires 2 values, a lower and an upper value.

Another question to validating business object properties. Is this the best way to test business objects? I want to specify validation rules just once, then I want to use them across different layers, like ASP.NET. I have never validated business objects this way, just on the client side. Can someone please tell me what is the best route to go with and if I am in the right direction?

Can someone advise?

Thanks Brendan

A: 

Why not set the upper bound of the validator equal to the maximum value of whatever type you are working with?

For example, if you are using Int32, do this:

[RangeValidator(1, RangeBoundaryType.Inclusive, 
Int32.MaxValue, RangeBoundaryType.Inclusive)]

As for best practice, centralizing your validation is always a tricky job and the Enterprise Library blocks are a very good solution for this problem. I think this approach is fine but it has its limitations (as do all attempts to solve this problem).

Andrew Hare
Thanks. What other validation frameworks have you worked with? Anything better than VAB?
Brendan Vogt
+2  A: 

VAB Experience

I have used the VAB to on projects for validation. I would say that it is good. I wouldn't go so far as to say it's great. No major issues so far. What I did find was that we did need to create some custom validators because our needs were not addressed out of the box. So it's extensible which is good. We did have issues with the configuration tool not being able to resolve our types (I think it's a bug in loading dependencies). The code runs fine but we had to do some configuration without the tool.

Validating a Numeric Unique Identifier

You're on the right track with the range validator. Be aware that each range (upper and lower) can have 3 different types: Inclusive, Exclusive and Ignore. This should cover most cases. In your case, you can specify the upper bound as ignore with the lower bound as 1 inclusive (assuming you want ProductId to be 1 or greater).

In configuration this would look like:

   <properties>
      <property name="ProductId">
        <validator lowerBound="1" lowerBoundType="Inclusive" upperBound="0"
          upperBoundType="Ignore" negated="false" messageTemplate="Oops...too low." messageTemplateResourceName=""
          messageTemplateResourceType="" tag="" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.RangeValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
          name="Range Validator" />
      </property>
    </properties>

Validating Business Object Properties

It sounds like you are on the right track. You should definitely always validate input to your business (or service) layer. If you also want to perform validation in the client tier then you can share your configuration or entities (business objects is what you called them) across tiers but you will have to ensure that the config or entities are synchronized between tiers. Another thing to consider if you are validating in two different tiers is how the ValidationResults will be displayed. VAB has integration with ASP.NET but once you call the business tier you won't have that integration so you will need another (custom) way to display those errors. (That may be as simple as a Label to dump the errors to.)

Now you're saying: ah, but if I validate in the web tier then I should catch all of the validation errors in ASP.NET and it all works nicely together. True. But that brings me to my last point.

VAB may be able to handle all validation but it probably won't be able to handle complicated validations. VAB is not going to do well if you have cross field (or cross object) validations. Also, you may need some custom validation in your business tier that you don't want to execute in the web tier (e.g. perhaps some validation depends on databases or external services that are not accessible from the web tier). So it's possible that you might end up with two different implementations to display validation/error messages.

Tuzo
Thanks for the detailed information. Do you think the Spring.NET validation framework will maybe be a better option? What other validation frameworks have you worked with? Anything better than VAB?
Brendan Vogt
@Tuzo: Have you read Tom Hollander's blog about configuration issues? It might solve your dependency issues: http://blogs.msdn.com/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx
Steven
@Tuzo: VAB does work fine when it comes to cross field or cross object validations. For cross field validations, you need to register the validator on the 'self' right below the `<ruleset>` element in the configuration or use the `[HasSelfValidation]` and `[SelfValidation]` attributes when defining validation inside the object itself. When it comes to cross object validations, this will be a lot harder, but that has nothing to do with VAB itself. Cross-object validations is hard per definition. I wrote about this on my blog: http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=49
Steven
@Steven: Thanks for the feedback. Yes, you can do almost anything with self-validation but my preference is to use the configuration. I guess the point is if you have non-trivial validation then VAB will not make it any less non-trivial.
Tuzo
@Turo: Don't forget that you can do self validation while using the configuration, while I must admit that adding those validations is a bit cumbersome. Nonetheless, you are right on: VAB or any other framework what so ever will not make non-trivial validation more trivial.
Steven