开发者

Using AOP techniques to intercept ADO.Net

开发者 https://www.devze.com 2023-03-02 03:59 出处:网络
I have quite a large code base using a variety of different ADO technologies (i.e. some EF and in some cases using ADO.Net directly).

I have quite a large code base using a variety of different ADO technologies (i.e. some EF and in some cases using ADO.Net directly).

I'm wondering if there is any way to globally intercep开发者_运维百科t any ADO.Net calls so that I can start auditing information like, exact SQL statements that executed, time taken, results returned, etc.

The main idea being that if I can do this, I shouldn't have to change any of my existing code and that I should be able to just intercept/wrap the ADO.Net... Is this possible?

EDIT

Its been suggested that I look into PostSharp, CciSharp or Afterthought, but how do I use one of these to get the desired results?


No. If you're coding directly against ADO.NET types you can't just tell DynamicProxy: "hey, put a proxy wherever I use SqlConnection in all these DLLs". DynamicProxy is a runtime proxy generator. It seems that you want post-compilation AOP, so look into PostSharp, CciSharp or Afterthought instead.

EDIT: if none of those tools are enough, you could use Mono.Cecil to directly alter your IL, but it's not easy. See for example:

  • http://www.codethinked.com/static-method-interception-in-net-with-c-and-monocecil
  • How to inject call to System.Object.Equals with Mono.Cecil?


vdh_ant:

I'm wondering if there is any way to globally intercept any ADO.Net calls so that I can start auditing information like, exact SQL statements that executed, time taken, results returned, etc.

Why not employ the profiling tools available in your RDBMS instead? They are more general in that they will capture all SQL statements and queries regardless of specific DB APIs. Futhermore, they provide standard performance analysis and statiscits right out-of-the box.

Another option is to write your own dummy ADO.NET provider, perhaps as a wrapper around the classes from System.Data.Common or around your specific provider if you need the DB-specific functionality. That wrapper could log the necessary information and delegate the real work to the underlying native provider.

0

精彩评论

暂无评论...
验证码 换一张
取 消