I can't say automagically but I can say boy this is confusing non intuitive code. Attributes in general make it hard to write code that is maintainable especially when attributes collide, or you remove on attribute and forget to remove another.
Attributes seem to muddy the water and when you have an attribute that is going to change the return value of a method I think this would lead to more confusion than the cool factor it is worth.
Jack - yes - the code is not intuitive.
I didn't say this was production ready - just that i had a cool idea and wanted to try it.
Obviously caching can be implemented with these attributes and _still_ keep the code readable.
Personally I like attributes and think they do contribute to readability - if acted upon correctly. the sample here is an extreme one and as such is just meant to make a point - you _could_ do this if you wanted to. now go and think of the possibilities to do this in a user/developer friendly manner.
hey Roy,
have you looked at the performance impact of the ContextBoundObject?
i'd heard rumors that ContextBoundObject was slow, but haven't tried it in practice.
i've looked at this approach vs. a post-compile step like XC# for injecting code via attributes. i'd like to have automated parameter validation via attributes, and it seems like one of these two approaches will work, but there are tradeoffs.
thx,
Kirk
Kirk - yes. It's somewhat costly, no doubt. That's why its very suited for Testing - which is usually somethign you expect can take a little more time.
FOr real world stuff I think it might be suited for various small corners which can allow less performance with better applicable benefit.
I'm still working out some ideas though.
I had cooked up something for Remoting that was similar to this using attributes and ContextBound objects. But because early on things about ContextBound were wrapped in the this is a very obscure corner of .NET and might go away in future versions enigma, I left it alone. ContextBound is very cool.
The problem with automatical solutions is that they usually don't know your intent and require explicit "hints" on how to act. for example, in the caching scenario you demonstrated- how/when are items invalidated? Since the caching is done orthogonally to the actual business scenario, the caching logic has no way of knowing or deciding what is a reasonable lifetime or invalidation criteria. And so you wind up adding more and more meta-data to the attribute. This then requires a delicate balancing game to ensure that the simplicity gained by abstracting the logic into attributes isn't lost due to the complexity of typing together two disparate systems - the application and the attribute-based framework.
I need a vacation.
Addy: I don't see why you couldn't expose the same sort of properties the HttpContext Cache does. That seems flexible enough. Even a very basic cache like:
<code>
public enum Expiration() { Absolute, Sliding }
AutoCache(Expiration expiration, long ms)
</code>
Can be very useful for quick/lightweight stuff, and realistically, it's probably as far as most developers ever go with caching for better or worse.
I'm personally more interested in validation attributes though...
<code>
// Property in User class:
[SqlBound(SqlDbType.Varchar, 30)]
[RegexValidator("[A-Z0-9_]{6,}")]
public string LoginName
{
get { return this._loginName; }
set { this._loginName = value; }
}
</code>
Actually I wrote an aspect driven caching system years ago and posted it to the learnasp.com lists. I revived the code on my blog about 8 months ago. I also wrote an aspect driven database adapter. The problem is that no one at the time seemed to care, and I gave up on it considering the coupling it creates.
The end result of my study was a conversation with a indigo team member. He told me that indigo would provide a 'real' AOP solution built around attributes called 'behaviours'.