Bits and bobs

Every business application must incorporate some kind of business logic and validate the response received from the user. There are a few ways to incorporate this logic through your application, which involve a mix of client and server side validations. This often means you will have some validation in your UI layer as Field validators and some logic in your business tier, where it is just not possible to bring to the UI such as verifying a date range does not overlap another set, or something which needs to access the database to verify against. The Validation Rules library attempt to unify this disparate approach to validation, and to automate some of the simpler validation logic such as required fields and field length validation. Instead of putting validation through the tiers, we can simply implement IValidation on the business object. This interface attaches a meta list of rules to the entity which we can build in the business layer and will propagate through down to th...

Where ever I go, what ever project I end up, no matter how simple the problem. I almost always end up having to deal with complex nested if statement. These statements seem logical at the time, but if left unchecked, grow into this special kind of monster which no one can decipher.... not even the guy who wrote it! A project I worked on recently was revolved around a booking engine. This engine contained the business logic which dictated how the a booking was processed, which state it would move to, what validation had to fire when, etc etc. It was split into several pages, all working on the same object (a booking) but a slightly different aspect of the booking. (pricing, accounts etc) I decided that it would be a good idea to run all the different aspects of the booking through the same method, thus encapsulating the logic of a booking, and hence having 1 place to maintain this logic. It sounded nice at the time, however, over the cource of the 6 - 12 months of developement with 5-6 ...