New Post: Building blocks for interception

@Unai Thanks for the feedback. The reason that AddInterceptor is not on DbConfiguration is that DbConfiguration is about setting up configuration for EF in the app domain such that it can be done in code but also discovered at design time. This makes it restrictive in how it works, most notably in that all configuration must be setup before EF is used. Interceptors on the other hand are not about configuring EF, but rather a dynamic part of the application that can (and likely will) change as the application is running. So it doesn't really fit in the DbConfiguration pattern.

Interception of command trees is something that we needed internally and seemed safe enough to make public. One use for it is to manipulate/rewrite command trees after EF has finished creating them. So, for example, if EF translates a query into a less-then-optimal query tree, then you could add re-writing to make the tree better. Unfortunately only query trees are currently publicly constructible, but we would like to also make update/insert/delete trees publicly constructible in the future. It's also worth noting that if you want to do something that depends on the semantics of the command (such as parameter inlining) then it is much easier to do this with the query tree than trying parse the generated SQL.

Thanks,
Arthur