2

I am trying to implement statistics reporting for internal components of an OLTP web application. For example, I want to track near real time the usage or performance of things like: number of successful/failed logins, number of nhibernate sessions, time to serve a HTTP request, number transactions of different types (orders, accesses, etc). All these stats are sent via UDP to a statsd server (https://github.com/etsy/statsd) and plotted as charts with Graphite.

The application is using dependency injection for wiring internal components. I want to centralize statistics reporting towards statsd server in a class of its own and hide it under an interface. However, I feel like injecting an instance of the stats reporting class/interface in every component of the application which is reporting performance or usage data to be a smell. It seems to me that performance reporting events should be something like a cross cutting concern, pretty much like logging.

How do you approach the internal design for such a request? Would you approach with constructor injection, static methods (e.g. PerformanceCounters.Increment("name.of.counter")) which are called my monitored components or how?

If it is of any help for context, the app is done in C# and is using ASP.NET and Castle Windsor as IoC.

Thanks, Robert

Robert Mircea
  • 699
  • 2
  • 10
  • 18
  • 1
    That's a cross-cutting concern just like logging. See this answer: http://stackoverflow.com/questions/7905110/logging-aspect-oriented-programming-and-dependency-injection-trying-to-make/7906547#7906547 – Mark Seemann Feb 22 '12 at 12:36

2 Answers2

1

I use Spring.Net for something like that. Spring is very like Castle Windsor for IoC, as far as I have heard of, and Spring uses CastleWindsor for creating dynamic proxies. These ones you can use for AOP, which is supported by Spring. The learning curve is short, the framework is very well documented. Once your performance aspect is configured, applying it to your methods should be more than easy. Let me know if you want a small sample.

Seb
  • 2,637
  • 1
  • 17
  • 15
  • The question is not about choosing a IoC container based on feature, it is about designing the solution from an architectural point of view. Anyway, how does code look like when approaching the request with Spring.NET? – Robert Mircea Feb 22 '12 at 11:41
1

The design pattern I think you are referring to is Aspect Oriented Programming. Castle Windsor supports AOP as do most other IoC containers.

You don't inject an instance of the stats reporting class/interface in every component, as you say. Rather, in your configuration, you wrap each component with an interceptor. The component knows nothing about stats reporting; the interceptor is invoked before and after every call to your component and can decide whether and where to send trace information. It's perfect for things like logging, tracing, performance counting, failure handling, and all those cross-cutting concerns you mention.

Tim Rogers
  • 21,297
  • 6
  • 52
  • 68
  • I understand that it is a cross-cutting concern, but it is not something like logging which "wraps" a method call. It doesn't seem right to count successful or failed login with the approach of interceptors/decorators of AOP. For example, if I handle the logic of logging-in in a controller action (ASP.NET MVC), how can I determine that the login is successful or not in order to increment the proper counter? – Robert Mircea Feb 22 '12 at 17:44
  • @Robert The log-in service you are using is presumably returning a value, setting some state, or throwing an exception to indicate whether log-in was successful or not. In your interceptor, you just check for this after the function call and act accordingly. This is absolutely an appropriate use of interceptors in my mind. And, while interceptors do "wrap" calls to underlying objects, you obviously don't have to do something both before and after: in this case, your interceptor would just append to the call. – Tim Rogers Feb 23 '12 at 09:44