Continuing my series on ASP.NET MVC ActionFilters, this time it's about the OnResultExecuting method (which runs before the result of the controller (e.g. ActionResult, ViewResult, etc) is run.

Since this filter runs after the action itself has completed, you won't be able to access any information about the action (except Route Data). The ResultExecutingContext has the basic context information that you've seen in the other contexts (HttpContext, Controller, RouteData), but it also has a "Cancel" bool property. If you set this property to true, the Result will not be executed (e.g. if it's a ViewResult, the View will not be returned to the browser; if it's a Redirect result, redirect headers will not be returned to the browser, etc). What you'll get by default is just a blank response with status code 200.

So why 'cancel' a result? You could substitute a cached view or replace it with some other response by directly manipulating the HttpContext. If the action returned a ViewResult, JsonResult, etc, you can still access the model passed to that result, to perform some logic or manipulate its properties.

As before, I created a kitchen sink view of ResultExecutingContext just for reference. I decided to put it in the ViewBag this time:

And here's a screenshot of the results in my browser:

One more to go in this series. As always, if there's something that you want more information or details on, feel free to leave a comment or send a contact form to me, and I'll be glad to help out in any way I can.

Surgery went well, thanks for asking. Now it's a few more months of rehab and I'll be almost good as new. I'm exercising my copy/paste skills again with this weeks Weekly Concerns link round-up:

• Using AOP with JSF for transactions when persisting data. Some Java stuff is Greek to me, but transactions are definitely a good use of AOP.
• DING for AOP in PHP
• Compile-time weaving is the only way to go with AOP on Windows Phone, here's an example that uses the PhoneCore framework.
• I'm most familiar with PostSharp, but it's always good to get other opinions on it. Here's a PostSharp review from Daniel Marbach.
• Speaking of PostSharp, Ward Bell recently did a live webinar about real world AOP usage at his company IdeaBlade. You can watch the recorded webinar, and IdeaBlade has also posted the code and slides used in that webinar.
• Finally, one more PostSharp link. This one is about using PostSharp for encryption/decryption. 

That's all for this week.

Do you agree with these concepts?

TDD is great, BDD is better. DDD is the way it should be done. SOLID principles should always be followed. Don't repeat yourself. Be agile. Follow the boy scout rule. Use an IoC tool and/or dependency injection. Don't reinvent the wheel. Always normalize your SQL tables. Use AOP to avoid boilerplate and clutter.

I do. And a lot of other people do too. But why? Because:

• ...it's been drilled into your head by peers and at software conferences?
• ...you have baggage from a previous job or hate your current job?
• ...you read about them all in a book like Clean Code, and assumed Uncle Bob knows what he's talking about?

Or have you actually researched and practiced each of these concepts and found them to be superior in many cases to the alternatives (which you've also researched and practiced)?

Well, for me, the answer is: all of the above. Except I don't hate my (current) job.

Yes, I just admitted that I've blindly subscribed to a lot of the tenets that you probably hold dear because of peer pressure and authority figures. This isn't necessarily a bad idea: authority figures and peer pressure can be useful constructs. But independent of your own healthy skepticism and critical thought, they can be dangerous too.

So before you run with any new acronym like BDD or AOP, do your research: see what your peers think, see what authority figures think, and finally use your own brain to put it all together.

I continue to try and cut through some of the confusion around AOP by providing simple definitions and examples of often obtuse terminology (see also: other terminology posts).

"Aspect" seems like the core term in "aspect oriented programming" doesn't it? An aspect is simply a way to indicate to an AOP tool: what and where. The "what" is the advice, and the "where" are join points.

Let's review the terms covered so far by looking at a very trivial example of AOP:

In that example:

• The join point is "OnEntry", i.e. before a method is executed
• The advice is the body of the OnEntry method (Logger.Write(...))
• The aspect is the MyAspectAttribute class itself
• The pointcut is a combination of the applied [MyAspect] attribute along with the join point
• i.e. the complete pointcut is "before the MyMethod method of MyClass is executed"
• in this illustration, it's a very specific pointcut, but useful real-world pointcuts would be broader
• The cross-cutting concern is logging (haven't gotten to that term yet; what's the rush, it's only the name of the site!)
• The weaving is performed by the PostSharp post-compiler (also haven't gotten to that term yet)

Looks like two more terminology posts to go. If there's a term that I'm missing or glossing over, let me know, and I'll write a post on it.

I will be under the surgeon's knife on Tuesday, so there probably won't be any posts this week. Hopefully, I will be able to resume posting at least once or twice next week, and get back to normal posting frequency within 2 weeks. Thanks for being a loyal reader of CrossCuttingConcerns!

If you have any short notes, blogs, or full articles that you'd like me to post here, please contact me; I'd be happy to post them!