拦截在实体框架6中无法正常工作

Question

我正在尝试遵循此处显示的拦截示例，以使其与EF 6配合使用，但遇到函数RewriteFullTextQuery的问题，如图1所示。该拦截似乎有效，但实际上并未执行for循环中的逻辑RewriteFullTextQuery方法的功能，因为cmd.Parameters.Count始终为零。 此外， cmd.CommandText属性似乎正在显示正确的SQL查询，我将其作为另一证据证明拦截工作正常。

图1：RewriteFullTextQuery代码摘录

 public static void RewriteFullTextQuery(DbCommand cmd)
    {
        string text = cmd.CommandText;
        for (int i = 0; i < cmd.Parameters.Count; i++)
        {
            DbParameter parameter = cmd.Parameters[i];
            if (parameter.DbType.In(DbType.String, DbType.AnsiString, DbType.StringFixedLength, DbType.AnsiStringFixedLength))
            {

图2所示的ReaderExecuting函数正在调用ReaderExecuting函数，该函数为其提供了引起所有麻烦的命令参数。

图2：ReaderExecuting功能

public void ReaderExecuting(DbCommand command, DbCommandInterceptionContext<DbDataReader> interceptionContext)
    {
        RewriteFullTextQuery(command);
    }

虽然我的代码是不完全一样的例子中，拦截似乎是工作，所以它是让我知道什么样的条件是将填充命令有Parameters.Count的大于零？

Answer 1

仅当您将参数作为变量传递给查询时，它才有效。 如果使用文字EF，则不会使用参数。
我的意思是，这不会生成任何参数

context.Notes.Where(_ => _.NoteText == "CompareValue").Count();

这将

string compareValue = "CompareValue";
context.Notes.Where(_ => _.NoteText == compareValue).Count();

Answer 2

事实证明，这是由于实体框架生成SQL的方式所致。 如果将字符串文字作为搜索值传递给LINQ语句，则它不会生成使用参数的SQL。 但是，如果您将搜索值作为变量传递，它将生成利用参数的SQL。 一个解决方案（用于动态查询）和更多详细信息可以在此Blog上找到。