Bonus recipe – Validation using RTTI attributes

Another benefit from structuring code in this way is that it is able to respond to different contexts of use. I want to show you a scenario to make you understand better: what if we have to validate the same BO form in different contexts? For example, an evolution of the application could be to add a login form. Since the customer is registered, we now have to authenticate it in the system, so we should add to the application a login form always based on the same BO—TCustomer. A solution could be to create another class (BO) with other attributes for the validation of the new login context, following the same steps as the previous one. What if another context based on TCustomer comes out? Another BO... and another one? Another BO... At the end, there will be n * BO representing the same entity, but in different contexts. So, this solution is neither very elegant nor an efficient one, because we are dealing with what is called a classes explosion, with all the negative consequences that derive from it.

A better idea is to add a simple context mechanism within the already implemented validation and attributes system to support different validation contexts, allowing you to always use the same BO. Further to this, I have supplied a bonus recipe that I highly recommend you analyze—Validation using RTTI attributes.