Archive for April 2009
Myth of Cambodia Geography Identification Code
How many of you are familiar with Cambodia Geography Identification code. Do you know the myth behind it code assignment? Well, it’s all started like this:
- There are 4 levels of administration
- Province
- District
- Commune
- Village
- Commune
- District
- Province
- Each level add up 2 digits begin with Province 2 digits
- Identification code are stored in numberic form (Integer)
That mean valid village code length bewteen 7 and 8 for example code 24020406 would identified as:
- Village Name = Ou Ressey Loeu (24020406)
- In Commune = Ou Andoung (240204)
- In District = Sala Krau (2402)
- In Province = Pailin (24)
Now suppose these Geography represent in 4 separate tables (SQL Server for ghost shack!)

By knowing a village code (eg: 24020406) I want to extract province code and I want the quickest way possible any thought? Oh ! there will be a reward for best answer.
Rhino-Tools a smarter Guard
When Ayende typed Guard.Against(condition, error_message) it clicked in my brain. I thought wow that was nice and easy to use what it does was check if the condition is true it will throw and exception with error message specify. I had an idea using this litle beast for business validation, since it doesn’t required any special configuration all you have to do is adding reference to Rhino.Common.Clr.dll.
However the original Guard API only has only two static method Guard.Against() it was limited for web application. In web application we might want to report back all problems so user can make the correction before they re-submit the form again, but using Guard.Against() we only catch one problem at a time, if we have multiple codition to check you can imagine how annoy for web experience.
Ayende is kindly enough accepting my patch for two additional method for the Guard bellow:
- Guard.Check(condition, error_message) – same behavior as Guard.Against() but it won’t throw and exception instead keeping records of problems
- Guard.Report() – until .Report() get call and exception known as GuardSpotException will be throw.
Let see how I can improve my usage experience with these methods
try{
new Guard()
.Check(pay.Date.Equals(DateTime.MinValue), "Invalid payment date.")
.Check(pay.Amount == 0, "Invalid amount, should it be something other than zero?")
.Report();
// persist pay instance to the database
}
catch(GuardSpotException ex)
{
// list of errors message
PropertyBag["errors"] = ex.GetErrorSummary();
}
First I instantiate a new Guard object and start checking conditions (business rules) finally I call Guard.Report() if there is any true condition (= business rule voilated) and exception known as GuardSpotException will be throw you then can catch and examin all problems.
Isn’t that cool?
