This project is read-only.

ASP.NET MVC - Best options to implent Application Log and Error Logs

Jan 31, 2014 at 6:29 PM
I would like to get some expert advise on setting up Application Log and Error Log in MVC Application. I see similar questions on Stackoverflow regarding this using Action filters. At the same time, people warn about over logging.

I would like to get your recommendations on this.

Feb 1, 2014 at 11:08 AM
The recommendations I usually point at are in this post. That Stackoverflow answer describes that injecting a logger into your services is often a design smell that can lead to maintainability issues. The solution is to apply Aspect Oriented Programming (AOP) where the logging cross-cutting concern is not injected into many services, but placed 'around' the services that need logging.

Applying action filter attributes to controllers is a form of AOP, so in that sense the recommendations in that Stackoverflow answer do not hold for you, since applying attributes is much better than having to duplicate that logging logic all over the place. However, if you end up applying those filter attributes to all controllers, you are still violating the DRY principle.

So instead of decorating controllers or actions explicitly, I believe it is possible in MVC to register certain filters on application start to be applied to all controllers. That would be much better.

Another approach that I'm quite fond of is to design the business layer in such way that the logging cross-cutting concern can be easily applied there. I've written a few articles (here, here and here). What these articles describe is an architecture where all requests to the business layer are done by passing messages to a few very narrow interfaces. Sending messages has many big advantages. Adding cross-cutting concerns for instance will be much easier. In the latest system I help built for one of my customers we wrote a simple LoggingCommandHandlerDecorator<T> that serialized the sent message to JSON and stored it in a transaction log. This way we could see what happened at any point in time, and we could even reply events (for load testing purposes) if we really wanted to.

I hope this helps.
Marked as answer by dot_NET_Junkie on 2/26/2014 at 1:14 PM