mvc logging: [LogRequest] vs OnActionExecuting

Question

i'm a .net/c# noob (long-time servlet/java developer)

i need to add logging to my mvc application. i want it to be fairly cheap performance-wise, and simple to configure.

what i would initially like to do is log each incoming controller action. it occurred to me that there might be a single-point-of-entry so i don't have to add a line of code to every controller's action methods.

the way i see it, i can either add a [LogRequest] attribute to the controller (in my case, a base controller) and then implement a

public class LogsRequestsAttribute : ActionFilterAttribute, IActionFilter
{
    void IActionFilter.OnActionExecuting(ActionExecutingContext filterContext)
    { ... }
}

class to handle the logrequest attribute.

or

i could just override the base controller as per:

public class BaseController : Controller
{
    protected override void OnActionExecuting(ActionExecutingContext filterContext)
    {
       // perform some action here
    }
}

and inherit all my controllers from BaseController.

in terms of performance, which would be quicker?

also, in terms of performance, i am considering putting the actual logging method call in a non-blocking thread that runs once and dies. any pitfalls with this approach? the goal is to let the app proceed and not wait around for the logging method to finish it's task.

score 4 · Accepted Answer · answered Sep 29 '11 at 16:46

If you're using MVC3, I'd recommend adding your action filter to the global filters collection rather than requiring a base controller. At app startup, in your Global.asax ("MvcApplication") class, you'll need a line like:

GlobalFilters.Filters.Add(new LogRequestsAttribute());

That will run it for all controller actions.

From a performance perspective, I don't think you'll see much difference between the attribute or the base controller mechanism. I've not tried it, but since the action filter portion of the MVC pipeline is going to run regardless of you having a base controller, the real consideration here would be flexibility rather than performance. The more flexible design is to isolate the logging from the controller.

I'd look at using a third-party log solution like log4net, which is already optimized for speed and well-tested. That will allow you to avoid having to spin up asynchronous logging threads and all that. Just log to log4net in your action filter and call it good. That also allows you to do the async portion of things on a per-appender basis - more control. If you need async logging, write your log4net appender to be asynchronous rather than wrapping all the various logging calls with async behavior.

thanks for the info. i understand what you're saying about log4net being optimized, but does it block? or will the logging filter you recommend just run asynch anyways? ... also one problem i have with log4net/j is the lack of customization with fields saved to the db. i want to add username and maybe a few other things to the log record and query on it later w/o having to do a "like" on the message field. — horace, Sep 29 '11 at 18:33
as for spinning up asynch logging, 'tis nothing: [link]http://www.singingeels.com/Articles/Logging_with_ASPNET_MVC_Action_Filters.aspx[/link] — horace, Sep 29 '11 at 18:36
i implemented this as per your rec and it's very nice. added the filter and it just works like magic! --- and i do like the fact that i don't have to worry whether a controller has some magical attribute associated with it for logging. simple. clean. works. — horace, Sep 30 '11 at 15:14

mvc logging: [LogRequest] vs OnActionExecuting

1 Answers1