Accessing registered rules for a given type

breakphreak posted on Thursday, July 29, 2010

hello again :)

http://forums.lhotka.net/forums/t/9292.aspx

In my previous question (please see the link above) I've described some authorization-related declarative approach we've decided to follow for now. In short, the attributes are declared on a particular interface, they are processed in a special place and converted into appropriate authorization rules to be registered with "BusinessRules" class.

I would like to make the approach even more handy:

 

• The attributes are decorating some particular BO interface (say "IMyEntity")
• That interface might inherit from another BO interface (say "IMyBaseEntity") that also might have some decorating attributes
• I am analyzing all the rules up to the hierarchy (IMyEntity -> IMyBaseEntity -> ... -> IEntityBase -> ... -> IBusinessObject)
• To avoid rules' collisions I want to provide an overriding-like behavior, i.e. if "IMyEntity" declared a particular rule, then the same rule if declared also for "IMyBaseEntity" will be silently ignored.
• This approach will also allow me to define some default rules, but decorating some application-level common denominator interface with some attributes that will trigger default rules registration. That behavior can be derived in descendants' interfaces, which is pretty nice.

 

The problem I've encountered, is that AuthorizationRuleManager is internal. Which means that I can't check if a rule is already declared for the particular interface. Also another method which is very similar to BusinessRules.EnsureUniqueRule() would be highly anticipated (the only difference would be the return value of type bool and not throwing an exception).

Assuming that I've succeeded to put my thoughts in the right wording - here is another place to ask for a better practice to implement the approach described above. The only alternative I can see from my narrow point of view is to turn the class into public. Since changing the 3rd party source is not the best thing to do, it would be great to hear your thoughts: do you think it worth to make the class public or there a better implementation is still possible with the current API?

RockfordLhotka replied on Thursday, July 29, 2010

At some point I plan to implement authorization attributes that work in a manner similar to the DataAnnotations validation attributes. If you want your model to fit into some future version of CSLA that is the basic approach you should consider.

I am hopeful that Microsoft will actually define the base for such an attribute. While it took them years, they eventually did this for validation. In other words, I'm in a position where I can either act now and rip it all out if/when Microsoft does something, or do what I did with validation and wait patiently for them to provide a supported model.

I suspect however, that the success of DataAnnotations will likely spur them to try the idea in the area of authorization sooner than later, so I think the risk of me implementing something and having to rip it out (and break everyone) is fairly high.

breakphreak replied on Friday, July 30, 2010

thanks a lot again! also, glad to hear that I am thinking in the right direction.

So I'll change the source (a bit) for now till the well-formed solution will arrive from the CSLA incubator :)