>>...all you have to do is have the Valid() event of a control talk to the rules object and just call that one method. Then you have the interface validating data using the exact same code used by the business object.
>
>I thought about this, but then you would be coupling your form and the bizrules object quite tightly.
>
>I was toying with the idea of creating a method simmilar to CheckRules, but to which I would pass the name of the field I'm validating and it would take care of calling the right validation method.
>
>Alex


Why wouldn't you just call the method responsible for validation directly? I understand not wanting to tightly couple the controls but I'm not sure your method would be worth the overhead or would be any less tightly coupled. You'd need to change the code in that method everytime you added controls that needed that same type of validation.

If was thinking, if the business rules enforced by the business rule class were objects themselves, you could do something like adding a "cName" property to them, then call the business rule class with the name of the individual business rule you wanted to check. (yeah, reread that sentence slowly - it's a little hard to understand ;-) ). You could register each "rule" with the class responsible for calling them via code, or data drive them. You could even get fancy and add a few more properties to them or create a few "types" of standard validation that get subclassed. Now you wouldn't really even have to write code to validate things like "Must Key" fields - just fill in a property with the error message, another property for with the field to check and you're done.

The main downside to this approach (besides the fact that you'd need to rewrite this layer in the framework) is that you'd be creating/destroying a lot of objects during validation so you'd want to use a lightweight baseclass for this.