Thanks for the suggestion. Unfortunately, the inability to deserialize entities as proxy objects is at the WCF/DataContractSerializer/Entity Framework level. Even if you overrode the DomainService's DbContext to turn Proxy Generation on the entities in the ChangeSet would be the base POCO objects, not the proxies, due to that limitation. For DbContext, proxies and lazy loading are disabled because proxy objects are not serializable without using the ProxyDataContractSerializer which just converts the proxy object into the base POCO for serialization.
Linq2Sql and Linq2Entities uses concrete classes, not proxy objects, so deserialization into the actual type is not an issue. The "rip out all the related objects" thing btw is a reason that lazy loading is turned off, but I recently discovered it isn't actually the main reason. The real reason is that serialization and deserialization occur before and after the DomainService is created and disposed of. If lazy loading was turned on, during serialization the entities would be throwing exceptions because the context would have been disposed of. This is the reason that you can't deserialize a proxy, the proxy has to be generated by the DbContext but at the time of deserialization there is no DbContext to create the proxies with.
All of that being said, it is possible that in the Web API version of Open RIA Services that there may be some other options available to us so I will keep your request in mind.
First I am very exited about this and Well done to everyone that made this happen..
After going through this,,
One thing about RIA Services / EF5 Combination that I am not happy about is the Proxy generation That is Disabled When Doing an Submit from SL Side. Not Worried about Queries
If I consume EF5 Directly from lets say an ASPX page. the Proxy generation works Perfect... If I check for Null on an related Entity And it is null I know there is NO reference on this Specific Entity.
If I consume EF5 From the RIA Service Submitchanges Call (I have created OnChanging/OnInserting Virtual functions on all my Entities Via an base Class) And I Check for Null I have to do LoadRefernce and then Again check for null . This Means I have to do an LoadReference On all my Relations Anyway.. So the Nice EF5 Proxy generation becomes useless. As it's disabled on Submitchanges.
You should not have to Add extra Code Inside your Business Rules Just to handle the differences between RIA Services and Direct ASPX access. As it should not matter what Service Layer are been used The behaviour of EF5 Should be the same.
I understand there is an issue that the Serialize could potentially rip out all the related objects, But is that not the Role of the [Include] Attribute to Control the Serilaizer's Behaviour. And For Submit Operations This also have an limited affect as only Changed Entity's Should be returned..
At least if it was possible to enable the proxy generation In Time on submit changes . But I could not find any event that would tell me it is an Submit And that successfully enable to proxy generation..
Can we Get the ability To Enable EF5 Proxy generation ON all submit operations ?
Ps..When I was using linq2sql Class with RIA services I did not have this problem.. How was it solved in that implementation...
Thanks for the response now it make perfect sense..
I Definitely need this fixed as it creating huge amount of null reference bugs in my code. on my CRUD operations
I will wait for branch 5 WebAPI version to solve this in the long run . For now I have to come up with some NASTY hack to try and fix this (: Anyone have any suggestion on the short term) ??
Will the WCF Source code be part of the Source code that we will receive from MS ?. It would be nice if we can get hold of that as I really need to try and do something about data compression for out of Brower as well. IF not then Branch5 is the ownly way out of this.. And I will have to wait..
No, we are not getting the source code for WCF itself.