More on AOP scenarios
The big scenario that always comes up WRT AOP programming is logging. I agree that that whole feature space - which I'll lump into the “instrumentation” bucket - is a good scenario, though AOP is obviously not the only the way to approach it.
What are the other scenarios? If you can give me an example in code on what you would do with this kind of support (or what people are already doing with it in the Java space), that would be helpful. It seems that the examples I'm looking at are all related to logging.
Comments
- Anonymous
June 30, 2004
Security is another I've heard mentioned. - Anonymous
June 30, 2004
My comments here:
http://blog.thetechnologist.net/PermaLink,guid,6aa7bbd8-d07b-42a6-97ee-c795464314d2.aspx - Anonymous
June 30, 2004
I guess I immediately think of the MTS/COM+ stuff: automatic transaction control, object pooling, JITA, ... - Anonymous
June 30, 2004
What about using AOP for the Observer Pattern? - Anonymous
June 30, 2004
I could be a bit confused, and indeed 'logging' may refer to my requirements, but I'd like to be able to treat methods and properties as first class objects (as in the prior post comment) for firing events, instead of continued code duplication. - Anonymous
June 30, 2004
The comment has been removed - Anonymous
June 30, 2004
Look under the user samples on GotDotNet under "Automatic Exception Handling".
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=44d0b1c7-4a9f-463b-bbac-952ea32b1a96 - Anonymous
June 30, 2004
The comment has been removed - Anonymous
June 30, 2004
All the AOP scenarios are easy to find - just speak to the SQL Server team and find out the scenarios people use Triggers for. In my mind, AOP and Triggers are very similar technologies - they are actions that occur out of sequence with the normal flow.
I find Triggers abhorent. - Anonymous
June 30, 2004
I've never done AOP with Java, but I used ContextBoundObject to do security and caching. - Anonymous
June 30, 2004
Eric,
I was thinking about this yesterday, after posting a couple of comments to your first thread on this subject. I find myself wishing that I could do this:
public void SomeMethod()
{
using(MagicMethodContext mc = new MagicMethodContext(SecurityLevel.EndUser))
{
//method body goes here
//mc.Transaction access a transaction
}
}
MagicMethodContext could do:
- security (raising exception on creation if user does not have SecurityLevel.EndUser - whatever that may be)
- logging, when it is created and then when its destroyed at the end of the block.
- transactions...
But there's one catch: when the object is destroyed at the end of the block, it can do "finally-style" cleanup, in its implementation of Dispose. But, it cannot tell if the "wrapped" code block raised an exception. If there was some way for MagicMethodContext.Dispose to tell whether or not an exception had been raised inside the "using" block, then it could do some intelligent clean up stuff - e.g. logging the exception, rolling back the transaction etc.
Of course, doing this with attributes would be nicer, and failing that anonymous delegates may come to the rescue by letting us pass the "body" code to a wrapper routine that does the try...catch etc. - Anonymous
June 30, 2004
In your MagicMethodContext, you could combine it with new StackTrace().GetFrame(1).GetMethod() to get the method of the caller. This way you can have a global definition of routines independent of any class-specific methods. - Anonymous
June 30, 2004
http://www.torqsoftware.com/blogs/apolon/2004/07/aop-and-net.html - Anonymous
June 30, 2004
The comment has been removed - Anonymous
July 01, 2004
The comment has been removed - Anonymous
July 01, 2004
The comment has been removed - Anonymous
December 18, 2004
Helpful For MBA Fans. - Anonymous
June 02, 2009
PingBack from http://uniformstores.info/story.php?id=42476