Change type of expression when deserializing

[vcaraulean]

Scenario:

• expression is built based on DTO type
• DTO has same shape as entity (or is a subset of entity properties)
• DTO is sent to the server

Now I want to deserialize expression and have the func executed over the my domain entity.

I got it working with serializing to json and doing a
string.Replace(typeof(DTO).FullName, typeof(Entity).FullName)

Is it the only way to achieve it?
Any pitfalls I may run in?

Thanks

[esskar]

hi,

this could be a nice feature. let me think about it, and i will integrate it in the next version.

cheers, esskar

[vcaraulean]

We'll, I'm thinking & playing with this idea and while it may work for simple & flat DTOs, it will be more difficult to achieve for complex cases:

• embedded DTO structures
• lists of objects
• embedded class definitions

In my case, I'm thinking now to reference in one way or another my server side domain from the client and use it to build queries...

[esskar]

i have 2 ideas:

1. build a mapper like automapper that maps 1 type to another type, but that would mean that you have to include the assembly of both types.
2. ignore the original types when a custom type is passed to the serializer, and use property name matching, but that would mean that you need to know the type before deserialisation

[vcaraulean]

On options:

1 - I think the effort will not justify the outcome. Flexible Fluent APIs are not easy to build, there are many pieces to be tied together.
2 - This sounds more interesting. You have to know only the "destination" type on which expression is operating. A simple option on ExpressionSerializer to say to skip type names and include only property names will do it...

2nd option opens another interesting scenario: turning an incoming JSON doc (or a simple string) with a query definition and execute it as an Expression<>. Take say, a query string from a web request, execute it on a IQueryable and return results... Like OData :)

[ghost]

I have the same problem.
Logically, DTO deserialized doesn't know mapped domain entity. But, we could add overloaded methods to .ToExpresion<>(), etc to make the replacement:
var domainExpression = expressionNode.ToExpression<Func<TResult , bool>>(stringDTO, stringDomainEntity);

Fixed comment .. Sorry, need TSource, TResult referenced...

A very good job, esskar!

[esskar]

I added a Expression<TDelegate> ToExpression<TDelegate>(Func<ExpressionNode, Expression<TDelegate>> conversionFunction)
is this helpful in any way?

[esskar]

it probably didn't.

but here is the deal. I made the ExpressionContext class and also the ToExpression(ExpressionContext)function public. I also extended ExpressionContextby the function ResolveTypeName. So what you need to do is implement your on ExpressionContext and override ResolveTypeNameto return types as you want them.
HTH

[ghost]

Ok.
I was testing your code and could not find the method... lol
By the way, does not compile the latest version downloaded now (MemberInfoNodeList and other errors).

However, this improvement is not a critical point. I can use AutoMapper mapping (with internal mapped "errors") the resulting expression, after replacing namespaces dto to domain entities.

I understand that "ConcurrentDictionary <string, ParameterExpression>" in ExpressionContext dictionary is serialized as a string expression and its parameters. Is that true? Because if so, I think your solution is perfectly valid.

THANKS!

[esskar]

ahhh, sorry for that. commited wrong.
fixed it now. please try again!

[ghost]

I tried basically. Now we can modify the expression delegating or driving context.
Looks good!

[esskar]

cool.
here is a blog post about it.
http://blog.esskar.de/articles/2013/1/serialize_linq_dto_and_business.html
Hope that helps.