First of all, I would like to say that I am a little nervous for posting about the topic because I know that a lot of talented people worked on the idea of adding type rules to the CSLA so I have a very strong feeling I am about to make a buffoon of myself. Unfortunately, I can’t help myself so here I go:
I am posting this because I seriously need to understand why type rules are touted to be such a good idea. I searched the forum looking for some good information regarding this subject but couldn’t find that much information. From the little that I read, apparently it all comes down to memory usage and speed. Supposedly, typed rules are faster and more efficient but I think the benefits are so minimum they are not really worth it, here is why.
To prove my point I would like to use an example so lets start by changing things a little, the first thing that I would like to do is to get rid of static RuleHandler delegate functions and replace them with normal static functions. Let’s take the “StringMaxLength” RuleHandler delegate function for this example. This function is currently implemented as follows:
public static bool StringMaxLength(object target, RuleArgs e)
{
int max = ((MaxLengthRuleArgs)e).MaxLength;
string value = (string)Utilities.CallByName(target, e.PropertyName, CallType.Get);
if (!String.IsNullOrEmpty(value) && (value.Length > max))
{
e.Description = String.Format(Resources.StringMaxLengthRule, e.PropertyName, max.ToString());
return false;
}
return true;
}
but I would like to take that and conver it to this:
public static bool StringMaxLength(string stringToEval, int maxLenght, RuleArgs e)
{
if (!String.IsNullOrEmpty(stringToEval) && (stringToEval.Length > maxLenght))
{
e.Description = String.Format(Resources.StringMaxLengthRule, e.PropertyName, maxLenght.ToString());
return false;
}
return true;
}
What we have avobe, is a strongly typed static function that can be shared by multiple classes, just like the old RuleHandler delegate function. Ok, now that we have that let’s look at the code that will take advantage of this new function. Since we want to limit the number of line of code that we need I will be using anonymous delegates in the code below. The code below is basically what goes inside the AddBusinessRules() method.
ValidationRules.AddInstanceRule(delegate(object target, Csla.Validation.RuleArgs e) { return Csla.Validation.CommonRules.StringMaxLength(_actualProp, 20, e); }, "PropName");
By the way, all this code is untested but I think it would work. The code above simply uses an anonymous RuleHandler delegate function to call the internal static method that runs the actual logic. Now lets analyze the pros and const.
To begin with, this function will by just as fast or sometimes a lot faster than using the old static RuleHandler delegate function if reflection is involved.
What about memory? Well, since we are using an extra anonymous RuleHandler delegate function as a wrapper the memory consumed by the type when its instantiated will be a little bigger but seriously…. How many more byte is that code gong to use? 3 or 4? Come on. Besides this code is code that belongs to the type so even if you instantiate thousands of these object the code inside is JITed once and used by all this thousands of objects.
What else? With type rules we can save a lot of memory because we only use one ValidationRulesManager objec rather than creating thousands of them? Well, couldn’t we also use a static ValidationRulesManager object to hold all of the instance rules as well if we wanted?
Doing it the way I suggest also makes code much simpler to understand, just look at all that had to be done to the project tracker StartDateGTEndDate function to make it work as a static function.
So exactly what is the big deal for having Type rules? Doing it the way that I propose we can also get rid of the “object target” parameter on the RuleHandler signature because it won’t be needed any longer (I think).
Please help, what I am missing here?
Copyright (c) Marimer LLC