Private field access inside an expression about serialize.linq HOT 6 CLOSED

I am not sure if i want to support private fields, because they are private!
Have to think about it!

from serialize.linq.

Consider the following scenario. The client builds the query against some stub data source, then the query is serialized and passed to the server. The server deserializes the query and applies it to the appropriate EF DbSet. From the client's prospective there is no difference if she uses a variable or a private field when she creates a Where clause:

var expression = Source.Where(row => row.Id == _rowId);

But in one case everything works fine, in other she gets a strange exception. The workaround for now:

var rowId = _rowId;
var expression = Source.Where(row => row.Id == rowId);

from serialize.linq.

Ok, i made it optional. On Serialization-Side you need to pass FactorySettings with AllowPrivateFieldAccess set to true, on Deserialzation-Side you need to set that property on the ExpressionContext

from serialize.linq.

Thank you. What do you think about providing two options:

1. Member should be read on serialization and replaced with a constant (for multi-tier scenarios)
2. Member should be read on runtime.
   Is it worth the time?

from serialize.linq.

Don't get it. Can you explain in detail?

from serialize.linq.

Lets assume we have an expression, that needs to be serialized:

var expression = People.Where(person => person.FirstName == firstName);

Right now the way that the expression is serialized depends on what 'firstName' is. If it is an instance field or a private static field, then the serialized expression will look like this (member access replaced with a constant):

People.Where(person => person.FirstName == "John");

If it is a public static field or a protected static field then the member access will be serialized 'as is':

People.Where(person => person.FirstName == SomeClass.firstName);

You can't pass that serialized expression to another tier, because SomeClass can be unreachable there.
Not sure why this happens, but you can see it in Issue54 tests. Probably this can be considered as an inconsistency - public/protected static fields should also be replaced with constants.
But I am guessing, what if user could specify how exactly an expression should be serialized? Can the option 2 (serialize 'as-is') be useful? Or the option 1 (replace with constants) is the only real-world scenario?

from serialize.linq.