Chorn Sokun's Weblog

Conquer inner fear, push it to the limit!

Posts Tagged ‘Rhino-Tools

Rhino-Tools a smarter Guard

with 4 comments

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?

Advertisements

Written by Chorn Sokun

April 10, 2009 at 10:37 am

Rhino-Tools, Sample Applications

with one comment

It had been quiet a while since I tried to allocate some time to get in deep with Rhino-Tools and my previous attempt was not fruitful. However I had learn that most of the problem that prevent me to run the sample project with the latest build (local build) because there is a mismatch assembly used.

Minimum Assembly Reference

Minimum Assembly Reference

The typical Rhino-Tools sample applications always make reference to assembly files stored in the SharedLibs in each sample applications’ folder and after every successful build of Rhino-Tools I always want to run the sample application again to see if it break anything. What I usually do is to copy assembly file from the ..\Build\net-2.0\debug & ..\SharedLibs\Castle folder to SharedLibs located in individual sample application folder.

This step is such a pain an annoying. I want to setup a system which I could later on forget about it. So to fix the problem one and for all is to reference needed assembly from it original location ..\rhino-tools\SharedLibs\Castle and ..\rhino-tools\build\net-2.0\debug this way we do not waste disk space for storing the same assemly files and since it is a sample project it doesn’t hurt a ship by doing so.

However I still recommend to copy the needed assembly to private folder and reference from there if you are working with your real world application.

Until this solution is adopted I need to add svn ignore roles SharedLibs in each sample applications folder.

Written by Chorn Sokun

July 24, 2008 at 11:58 pm