none
Object safety/validation RRS feed

  • Question

  • All,

    I know this is probably a stupid question, but I am trying to think out of the box.

    I have long been a believer that layers/components/objects should protect themselves from bad data. I often write APIs that are being used by client developers, and sometimes the validation is not as diligent as I would like. For example, given an address class that contains a zip-code field (defined as a String), and someone thinks it would be useful to put the text "AAAAA" into that field. Unfortunately, this results in "AAAAA" getting placed into the database and another application blowing up because it expects a real zip-code.

    Anyway, what I have done for years is perform validation checking inside of the class itself, usually in the property setter (if available) and in the constructor. Invalid sets throw an exception. Unfortunately, this kind of code is tedious at best. So, I was wondering what the readers of this forum thought of that approach, and if there was a better approach.

    There are only 2 requirements: it has to be able to be implemented in C# for .NET 3.5, and the validation has to be done.

    Thanks is advance
    Chris Snyder, Stumbling through code one day at a time If your question was answered, please mark it.
    Tuesday, June 16, 2009 7:53 PM

All replies

  • I do validation this way as well. There are a few things available in Visual Studio that you can use to help with this code. First, if you use databinding, you can use the ErrorProvider control. That means that your validation can show validation icons instead of having to handle exceptions. (Assuming here that you are doing WinForms).

    I have an example here:

    http://www.insteptech.com/techLibrary/samplecode.htm

    It includes validation.

    Hope this helps.
    www.insteptech.com
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Tuesday, June 16, 2009 7:59 PM
  • Deborah,

    Thanks for the reply. I have used the ErrorProvider in the past for client-side objects. (The particular example I'm thinking of is deep in the server code, so that does not apply)

    The reason I ask is that I've been doing the property/constructor validation inside of the object for a long time now. I was looking to see if someone had come up with an interesting use of a pattern or other mechanism to handle validation. (Other than ignoring it, of course.)

    Plus, I'm kind of leading up to a more 'interesting' question ;)

    Chris
    Chris Snyder, Stumbling through code one day at a time If your question was answered, please mark it.
    Wednesday, June 17, 2009 12:24 AM
  • Hi

    there's been some discussion on this topic lately
    http://jeffreypalermo.com/blog/the-fallacy-of-the-always-valid-entity/
    http://codebetter.com/blogs/gregyoung/archive/2009/05/22/always-valid.aspx

    Personally I think it depends on what kind of system you are building..

    I agree that entities should protect themselves from bad data when you are building a *real* domain driven design.
    But, if you are only building glorified DTO's I feel that there a better ways to do this..

    One of the approaches I've personally taken a few times is declarative validation: using attributes to validate objects
    Take a look at the Validation Application Block in Enterprise library, it's a good starting point...
    However writing your own (which I've done on several occasions) isn't that hard either.

    Basically you put the validation logic inside an attribute (eg MaxLength of a field etc).  At runtime you get the attributes instances off the type and pass in the values for said properties and so forth.

    In the end this gives you a (composite) validation result which shows what properties are valid/invalid.
    If you play your cards right you can even return a validation result to the client to show what was going wrong..

    Main point after that is integrating it back into the UI.
    Here you have a number of solutions, you can use a binder approach (an object which *knows* both the controls and the properties they are bound to) which allows you to push back the validation result to the controls.

    KR

    Frederik


    Please close the thread if your question is answered, and don't forget to rate the best responses!
    Wednesday, June 17, 2009 7:41 AM