What’s the big deal about Type rules???

rxelizondo posted on Tuesday, October 17, 2006

Could someone PLEASE tell me EXACTLY what is the big deal about Type rules?

 

I am under the impression that Type rules where added because of some tremendous benefits but I have failed to see such benefit.

 

Please educate me.

 

Henrik replied on Tuesday, October 17, 2006

The benefit from using type rules is that each instance of a type doesn't load it's own "copy" of the rules into memory. With type rules only one "copy" of the rules is created and stored in memory. The type rules makes each object more lightweight and faster.

For more info, see Rocky's change log for 2.1 at http://www.lhotka.net/Article.aspx?area=4&id=f12cc951-0452-42d1-96a6-cfa7656863b1

/Henrik

rxelizondo replied on Tuesday, October 17, 2006

Thanks,

 

Well, I was poking around the CSLA code when all of the sudden I stumbled upon the BusinessBase constructor and a lot of thing started to make sense, specifically, I noticed that this constructor has the following two lines of code:

 

if (!Validation.SharedValidationRules.RulesExistFor(this.GetType()))AddBusinessRules();

if (!Security.SharedAuthorizationRules.RulesExistFor(this.GetType()))AddAuthorizationRules();

 

Now I can understand how type rules can reduce load type and memory overhead.

 

Well, with my new founded knowledge, I think I am ready to make a fool of myself again and make a suggestion regarding how to make the decisions on whether to use type rules or instance rules more clear cut. This suggestion may be absurd since I am still new to the CSLA but here I go:

 

I suggest changing the signature of the instance RuleHandler from:

 

public delegate bool RuleHandler(object target, RuleArgs e);

public delegate bool RuleHandler<T, R>(T target, R e) where R : RuleArgs;

 

To:

 

public delegate bool RuleHandler(RuleArgs e);

public delegate bool RuleHandler<R>(R e) where R : RuleArgs;

 

The reason I am suggesting this change is because if you think about it, you don’t have to have the “target” parameter on instance rules because when you create instance rules you have access to the actual object so what’s the point.

 

Further more, making this change will make it really clear on when to use type and instance rules because the CSLA would crash if you where to try to push a type handler into and instance rule or vise versa.

 

Does this make sense to you?

ajj3085 replied on Wednesday, October 18, 2006

I believe RuleHandler is shared by both type and instance rule methods, so this would be a breaking change (and we've already had one of those).

Trying to use a non-static rule on an instance will cause a run-time exception as well, so there's not much danger of bugs because of getting the rules mismatched.

rxelizondo replied on Wednesday, October 18, 2006

In my opinion, breaking changes are simply a fact of life and there is not much we can do about it.

 

I think one of the primary aims of the framework should be towards simplicity of use. Having an instance RuleHandler that accepts a “target” parameter for no good reason simply creates complexity.

 

I think I remember reading a post where Rocky expressed concern regarding the complexity of having two types of rules. I definitely agree that two types of rules adds complexity and I am just proposing a way to make the decision about when to use de different rules much more straight forward.

 

Anyone else has an opinion regarding this subject? Rocky, what do you think?

 

ajj3085 replied on Wednesday, October 18, 2006

rxelizondo:

In my opinion, breaking changes are simply a fact of life and there is not much we can do about it.

Framework authors fortunately try to avoid breaking changes whenever possible, because they make it harder for us developers to move to newer versions.   If a change is breaking but the result of that change is very compelling then I'm all for it.  The change you suggest doesn't buy us anything we don't already have.  You can't expect to sit down and use any moderately complex framework just by looking at method signatures.. you need documentation, which for Csla is the book and coming ebooks.

rxelizondo:

I think one of the primary aims of the framework should be towards simplicity of use. Having an instance RuleHandler that accepts a “target” parameter for no good reason simply creates complexity.

There's nothing stopping you from using the target parameter.  At any rate, instance rules are the exception, not the norm.  That is, in almost all cases you'll be using type level rules.

rxelizondo:

I think I remember reading a post where Rocky expressed concern regarding the complexity of having two types of rules. I definitely agree that two types of rules adds complexity and I am just proposing a way to make the decision about when to use de different rules much more straight forward.

The concerns were addressed.  For example, the runtime exception if you try to add an instance rule as a type rule.  The framework detects this and gives a clear exception at runtime.  Having two different levels does make things a bit more complex, but that complexity also gives great flexibility.

I think this is the thread you are refering to, and I think you can also see that the resulting discussion aleviated the concerns that Rocky and others had.

rxelizondo replied on Wednesday, October 18, 2006

ajj3085 :

 

Well, I am speaking for the new generations that will be learning and adopting the CSLA framework. The idea is to keep the framework simple, we are already starting to see some awkward code in the CSLA in the name of backwards compatibility that just makes things complex for new user.

 

Now, lest just supposed that this new change was implemented, how big of a deal would it be to make the changes on our programs?

 

Since most people would already be using type rules, chances are making this change will not break any code at all for the people following the use only type rules patters.

 

But what about the people that do use instance rules? Well, all they would have to do is remove the “target” parameter from their functions and all should work just fine, is that really that much of a big deal?

 

Thanks.

ajj3085 replied on Thursday, October 19, 2006

rxelizondo:

Well, I am speaking for the new generations that will be learning and adopting the CSLA framework. The idea is to keep the framework simple, we are already starting to see some awkward code in the CSLA in the name of backwards compatibility that just makes things complex for new user.

Well, new users should pick up a copy of the book.  The framework is a marketing tool for the book, not the other way around.  And Andres raises a good point; every other delegate in the .Net framework includes the object which is 'causing' the event.  Keeping consisitent with the .net framework itself is a good ideas.

rxelizondo:

Now, lest just supposed that this new change was implemented, how big of a deal would it be to make the changes on our programs?

Some people will have to change all or most of their classes.  For absolutely zero added benifit.

rxelizondo:

Since most people would already be using type rules, chances are making this change will not break any code at all for the people following the use only type rules patters.

We don't know this for a fact though.  Its entirely plausable that people simply change the call to AddInstanceBusinessRules and left it at that.  That's a valid way to update your code to use 2.1 as well. And again, you're forcing people to change code for NO benefit whatsoever.  The addition of type rules adds a very compelling reason to upgrade and update your existing code, which is why the community supported the breaking change.

rxelizondo:

But what about the people that do use instance rules? Well, all they would have to do is remove the “target” parameter from their functions and all should work just fine, is that really that much of a big deal?

Why should they have to do anything at all?  There's no benefit at all to existing users from this change.  Add in Xal's comments, and you're actually making things more confusing, because the Rules delegate pattern is different than any other delegate pattern in the framework.  You could make the same argument for Form events.  Sender is always the form, yet you have access to the instance properties, so they should remove that.  I don't think that's a good idea either.

xal replied on Wednesday, October 18, 2006

There are good reasons for keeping those delegates that way.
1st, all event handlers in .net use that type of delegate, so it's something we're used to see.
2nd, suppose you have a complex case where, for some reason, you want an outside live object to validate stuff... I can think of a common object that has parameters and validation rules based on those parameters that would apply to many objects. In that scenario the target would be needed, and the method wouldn't be static.

Anyway, the target parameter is just there for flexibility, and you are in no way forced to use it if you use instance rules.

Andrés

rxelizondo replied on Wednesday, October 18, 2006

xal:

 

Not sure I follow your example but I think you are referring to the idea of having the ValidationRules object call instance objects outside the object that is hosting it.

 

If I understand your example correctly, I think you could still do the same thing using a type rule that will then delegate the call to the instance (live) object.

 

I agree with you that flexibility is nice, as long as there is a point to that flexibility, for me having a “target” parameter on instance rules is akin to someone climbing Mount Everest carrying a bowling ball with them, since they wont find a bowling alley up there, what is the point on having the extra weight.

 

Thanks.

Henrik replied on Wednesday, October 18, 2006

I for one would oppose strongly against changing the signature, if the breaking change is only for the beauty of our code. I've adopted the breaking changes from 2.0 to 2.1 due to the major memory and performance improvements of type rules.

I've already released 2 apps last week based on v2.1 and I don't want to neither alter the code in these and re-release nor keep a v2.1 and a v2.1.1 side by side just because newcomers needs simplicity. In the end I think having one signature of rules is the simplest anyway.

Cheers
/Henrik

rxelizondo replied on Wednesday, October 18, 2006

Henrik:

I think is *very* important to make it as easy as possible for newcomer to adopt the framework, after all, they are the ones that will make the CSLA an even bigger success.

 

There are 3 things to note here:

 

1. These breaking change do not have to require a new release, this change could be added when other braking changes are also required (you know they will happen).
2. This is not beauty code changes, in my opinion this are logical changes. Like I said before, there is absolutely no reason why the RuleHandler should require the “target” parameter for instance rules.
3. Other than making the code more logical, having different RuleHandler signature will allow the compiler to verify that you are adding static methods to type rules and instance methods to instance rules during compile time and not wait until runtime. 

One last thing, if you adopted the type rules already then your code should NOT require any changes so it should have zero impact on the applications you already distributed.

 

ajj3085 replied on Thursday, October 19, 2006

:

I think is *very* important to make it as easy as possible for newcomer to adopt the framework, after all, they are the ones that will make the CSLA an even bigger success.

Rocky's goal isn't to have everyone adopt Csla.  His goal is for people to buy the book.

:

These breaking change do not have to require a new release, this change could be added when other braking changes are also required (you know they will happen).

You're asking people to spend time changing code when in the end they will have zero benefit.  I find that hard to ask of anyone..

rxelizondo:

This is not beauty code changes, in my opinion this are logical changes. Like I said before, there is absolutely no reason why the RuleHandler should require the “target” parameter for instance rules.

No offense, but so far no one else seems to agree.

rxelizondo:

Other than making the code more logical, having different RuleHandler signature will allow the compiler to verify that you are adding static methods to type rules and instance methods to instance rules during compile time and not wait until runtime.

While catching exceptions earlier is good, in this case the exception is thrown as soon as you try to instanciate the object.. fairly early on, and likely to be caught by any kind of testing.  So unless you check in code, and immediately release to production (which is a huge mistake to begin with) you won't have a problem.

ajj3085 replied on Thursday, October 19, 2006

rxelizondo:

I agree with you that flexibility is nice, as long as there is a point to that flexibility, for me having a “target” parameter on instance rules is akin to someone climbing Mount Everest carrying a bowling ball with them, since they wont find a bowling alley up there, what is the point on having the extra weight.

We've explained what object comes in as target.  You're free to use it or ignore it.  How is having it there hindering you in any way?

rxelizondo replied on Friday, October 20, 2006

Further investigation of the CSLA code revealed that it is possible to add static functions to instance rules. I already knew this but I had forgotten.

 

Needless to say, if instance rules allow for static methods then the MethodHandler signature must remain the way it is right now, end of discussion.