locked
Architecture question: Share validations between client & server RRS feed

  • Question

  • Hello again experts!

    We're currently developping an application using MVVM and a SOA.  The flow of this application looks a bit like:

    View (WPF) => ViewModel (C#) => Model (C#)=> ServiceProxy (C#) **Client** ====> **Server** Process Service (C#, WCF)=> Capability/Activity/Entity Service (C#, WCF)=> Database (MS SQL)

    Now, there's two locations where business logic is checked: the client (View - fieldvalidation / masks / ... ) and the server (Proces Service).  At this point, both the client and the server implement their own methodology to check the input.  For instance, if there's a field where the user can enter a positive value with a maximum of $999.99:

    - the view will have a mask on the text edit field, allowing only numbers (and seperator characters), and limiting the maximum length of the field to 5 characters.  (I know this last doesn't make sence, but it's only an example.  We use DevExpress Text Edit, it has built in validation structures)

    - the process service will check the input parameter for being greater then 0.00 and less then 1 000.00

    The problem ofcourse with this approach is that when there's a change in business logic (for instance: the new maximum allowed value is now $5 000.00), both the server & the client need to be updated, each in their different way.  Another problem is that we essentiallly have the view checking the input, but when a new view (or new application) is written on our models, the validation logic needs to be rewritten & updated when changes occur aswell.

     

    My question is: how can we reuse the validation, both in the model (client) and the process service (server)?  Is there any standard approach to this? Validation framework? Guidelines? Design patterns?

     

    Thanks in advance to anyone's $0.02!

     


    "The improbable we do, the impossible just takes a little longer." (Steven Parker)
    Wednesday, October 27, 2010 8:50 AM

Answers

  • In the end, after a 6.5 hours architecture meeting yesterday, we decided to develop a custom approach for this.

    We realised there's a difference between what we'll call "static" rules, "foreign key entity" and "dynamic" rules.

    Static rules would be: a barcode (EAN13) can only contain digits.  A value can only contaign digits, seperators, and the minus sign (locale dependant ofc).  These static rules will be checked client & server, and where possible, the UI will limit the possible input by the user, hardcoded in XAML...

    Foreign key entity rules would be: one can never transfer money from an account that doesn't exists, or to an account that doesn't exist.  For performance reasons, this will only be checked on the server.  These rules in a way are also static: none of our customers will ever say: "but I want to allow transfering funds from an account that doesn't exist."

    Dynamic rules would be: the minimum and maximum amount of one account transaction.  This is customer specific, business dependent.  Will be checked client & server.

     

    The basic idea is to be able to tag (annotate ofcourse) any parameter or field with one or more "validation rules", by providing the rule's name.  These rules would be provided by our configuration service (think service oriented architecture), and thus sharable between client & server.

    The thing is that the client can not do all validations the server can (the foreign key entity rules), but that's just a matter of providing 2 "rule to validation object" builders, both able to handle all rules, but sometimes producing different validation objects.

    The final step will be to update our configuration tool for the configuration service, so that we / our helpdesk / perhaps even the customer, can, in a limited way, update the business rules of the application on the fly.

     

    We might (and I hope we can, it's always a legal thing...) share this code with the community when it's finished...

     

    Kind regards

     

    JR


    "The improbable we do, the impossible just takes a little longer." (Steven Parker)
    Thursday, October 28, 2010 6:57 AM

All replies

  • I'd just like to add that I am perfectly capable on entering ".NET Validation Framework" in google myself, I'm just looking for some real life experience here...
    "The improbable we do, the impossible just takes a little longer." (Steven Parker)
    Wednesday, October 27, 2010 9:07 AM
  • In the end, after a 6.5 hours architecture meeting yesterday, we decided to develop a custom approach for this.

    We realised there's a difference between what we'll call "static" rules, "foreign key entity" and "dynamic" rules.

    Static rules would be: a barcode (EAN13) can only contain digits.  A value can only contaign digits, seperators, and the minus sign (locale dependant ofc).  These static rules will be checked client & server, and where possible, the UI will limit the possible input by the user, hardcoded in XAML...

    Foreign key entity rules would be: one can never transfer money from an account that doesn't exists, or to an account that doesn't exist.  For performance reasons, this will only be checked on the server.  These rules in a way are also static: none of our customers will ever say: "but I want to allow transfering funds from an account that doesn't exist."

    Dynamic rules would be: the minimum and maximum amount of one account transaction.  This is customer specific, business dependent.  Will be checked client & server.

     

    The basic idea is to be able to tag (annotate ofcourse) any parameter or field with one or more "validation rules", by providing the rule's name.  These rules would be provided by our configuration service (think service oriented architecture), and thus sharable between client & server.

    The thing is that the client can not do all validations the server can (the foreign key entity rules), but that's just a matter of providing 2 "rule to validation object" builders, both able to handle all rules, but sometimes producing different validation objects.

    The final step will be to update our configuration tool for the configuration service, so that we / our helpdesk / perhaps even the customer, can, in a limited way, update the business rules of the application on the fly.

     

    We might (and I hope we can, it's always a legal thing...) share this code with the community when it's finished...

     

    Kind regards

     

    JR


    "The improbable we do, the impossible just takes a little longer." (Steven Parker)
    Thursday, October 28, 2010 6:57 AM