Proposal: Built-in extensibility for structured logging (commands, parameters, connections, transactions)

Hi,

I'm currently looking for a robust way to implement logging with Dapper and would like to propose (or ask for guidance on) a more integrated/extensible approach.

Use case:

• Log executed SQL statements including expanded parameters
• Log connection lifecycle events (open/close), ideally with relevant (safe) metadata from the connection string
• Optionally log transaction boundaries (begin/commit/rollback)
• Ability to enable/disable logging easily (e.g. enabled in development/staging, disabled in production)

Problem:
I’ve experimented with wrapping DbConnection / DbCommand, but this tends to:

• break or interfere with Dapper internals (e.g. list parameter expansion for IN (...))
• become fragile and hard to maintain across different providers

Question / proposal:
Would it be possible to introduce an official extensibility point (e.g. interceptor, pipeline hook, or diagnostic listener) that allows:

• inspecting the final command text + parameters as Dapper executes it
• observing connection and transaction events without wrapping providers
• plugging in logging in a clean, opt-in way

Something similar in spirit to logging/interception patterns in other ORMs would make this much easier and safer to implement.

I'm limited in knowledge to be able to contribute or help refine the design but I hope this is something that could fit within Dapper’s scope.

Thanks!

No files, tests, or entry points are named. Start by reviewing Dapper's command execution and connection/transaction handling paths, then check whether existing diagnostics or extension points cover them. Done would require a decided, opt-in design for command, connection, and transaction observation, including parameter handling and enable/disable behavior.