Putting a business rule into code on a form would probably be the worst possible option because the only way to reuse code like that is copy & paste (unless you want to instantiate an invisible copy of the form, fill controls with values via code and then 'push' a button programmatically - yes, I've seen people doing this).

Putting a business rule into a 'BizObj' is slightly better because this allows code reuse and eases development/maintenance, and for a single-executable/single-user solution it may indeed suffice. Even for multi-exe it may be a good option if the only alternative would be to use DBCs (i.e. when the solution is not built on a database) but you have to ensure that all copies of all executables contain the same revision of 'BizObj'.

But the normal place for an integrity rule is a point where a single instance governs all access to the data. This guarantees best results at the least cost. Performance considerations may require additional 'instances' of the rules closer to the user (BizObj, perhaps even form/controls) but the purpose of these instances is no longer integrity protection, it is merely predicting & preventing potential trouble (so to speak). If these additional instances fail then nothing is lost except a little performance.