使用AOP技术拦截ADO.Net
我有相当大的代码库，使用各种不同的 ADO 技术（即一些 EF，在某些情况下直接使用 ADO.Net）。
我想知道是否有任何方法可以全局拦截任何 ADO.Net 调用，以便我可以开始审核信息，例如执行的确切 SQL 语句、花费的时间、返回的结果等。
主要想法是，如果我可以做到这一点，我不必更改任何现有代码，并且我应该能够拦截/包装 ADO.Net...这可能吗？
编辑
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 intercept 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不。如果您直接针对 ADO.NET 类型进行编码，您不能只是告诉 DynamicProxy：“嘿，在所有这些 DLL 中使用 SqlConnection 的地方放置一个代理”。 DynamicProxy 是一个运行时代理生成器。看来你想要编译后 AOP，所以看看PostSharp， CciSharp 或 事后思考 代替。
编辑：如果这些工具都不够，您可以使用 Mono.Cecil 直接更改您的 IL，但这并不容易。例如，请参见：
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:
vdh_ant：
为什么不使用 < em>RDBMS 而是？它们更通用，因为它们将捕获所有SQL语句和查询，而不管特定的DB API。此外，它们还提供开箱即用的标准性能分析和统计数据。
另一种选择是编写您自己的虚拟 ADO.NET 提供程序，可能作为来自
System.Data.Common的类的包装器，或者如果您需要数据库，则作为您的特定提供程序的包装器-特定功能。该包装器可以记录必要的信息并将实际工作委托给底层本机提供者。vdh_ant:
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.Commonor 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.