Использование методов АОП для перехвата ADO.Net

Question

У меня довольно большая кодовая база, использующая различные технологии ADO (например, некоторые EF, а в некоторых случаях напрямую ADO.Net).

Мне интересно, существует ли какой-либо способ глобального перехвата любых вызовов ADO.Net, чтобы я мог начать аудит такой информации, как точные выполненные операторы SQL, время, возвращенные результаты и т. Д.

Основная идея заключается в том, что если я смогу это сделать, мне не нужно будет менять какой-либо из моих существующих кодов, и что я смогу просто перехватить / обернуть ADO.Net ... Возможно ли это?

РЕДАКТИРОВАТЬ

Было предложено посмотреть PostSharp , CciSharp или Запоздалая мысль , но как это сделатьЯ использую один из них, чтобы получить желаемые результаты?

Answer 1

Нет. Если вы кодируете напрямую для типов ADO.NET , вы не можете просто сказать DynamicProxy: «Эй, поставьте прокси-сервер везде, где я использую SqlConnection во всех этих DLL». DynamicProxy является генератором прокси времени выполнения . Кажется, вы хотите после компиляции AOP, поэтому посмотрите вместо этого PostSharp , CciSharp или Afterthought .

РЕДАКТИРОВАТЬ: если ни один из этих инструментов не достаточно, вы можете использовать Mono.Cecil, чтобы напрямую изменить свой IL, но это не легко. См. Например:

• http://www.codethinked.com/static-method-interception-in-net-with-c-and-monocecil
• Как ввести вызов System.Object.Equals с помощью Mono.Cecil?

Answer 2

vdh_ant

Мне интересно, существует ли какой-либо способ глобального перехвата любых вызовов ADO.Net, чтобы я мог начать аудит такой информации, как точные операторы SQL, которые выполнялись, время, возвращаемые результаты и т. Д.

Почему бы вместо этого не использовать инструменты профилирования, доступные в вашей RDBMS ? Они являются более общими в том, что они будут захватывать все операторы и запросы SQL независимо от конкретных DB API s. Кроме того, они предоставляют стандартный анализ производительности и статистику прямо из коробки.

Другой вариант - написать своего собственного фиктивного ADO.NET провайдера, возможно, в качестве оболочки для классов из System.Data.Common или вокруг вашего конкретного провайдера, если вам нужны специфичные для БД функции. Эта оболочка может регистрировать необходимую информацию и делегировать реальную работу базовому нативному провайдеру.