Make parameterization of global query filters more obvious

From below:

Notes from triage: the current design of query filters uses the DbContext as the anchor from which filter parameters are read. This works well in many cases, but has a couple of limitations:

• People don’t get it. That is, many times we see code that attempts to hard-code the filter value into the model and then re-build the model for each context instance. This can be made to work, but only with terrible perf characteristics, which makes it a pit-of-failure.
• It requires a stronger coupling of the DbContext type to the entity types being used than is ideal–essentially the issue reported above.

Based on this, it might be worth designing and implementing query filters where the filter parameter is obtained in a different way–such as through a defined callback. This would be easier for many to understand and would not have a strong coupling to the context.

---

Original issue:

For a enterprise level application you cant define an entire data model directly on the DbContext, you use IEntityTypeConfiguration<TEntity> to seperate configuration away from OnModelCreating method.

When it comes to HasQueryFilter that uses expressions with dependencies to scoped members there is no such mechanics. It needs to be defined directly on the DbContext. This just wont cut it for a large Enterprise level application.

[joshcomley]

@AndersMalmgren this won’t apply the query filters to any .Include(..) you use. Just want you to be aware of the security risk of doing that; your API may expose unwanted data via expands.

[AndersMalmgren]

No, If any entity has a relation to another entity that is under restriction that entity also needs to have filters. Thats ok in our case. Child and parents always have same restrictions.

We dont use Include but we project all queries to DTOs that might include children