Building blocks for interception

Topics: EF Runtime
May 2, 2013 at 4:58 PM
Edited May 3, 2013 at 8:38 AM
I'm try to review the commit about "building blocks for interception" and I have some questions about the design of this "super" feature :
  1. Why the Interception.AddInterceptor and not a new method in DbConfiguration (This is the same obsolete pattern like Database.SetInitializer<>).
  2. Is IDbCommandTreeInterceptor an interface designed for developper? Wich is the scenario to create a new interceptor based on this interface?
best regards,
Unai Zorrilla
May 10, 2013 at 1:04 AM
@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.