UnitOfWork2 serialization for WCF

Posts   
 
    
ww
User
Posts: 83
Joined: 01-Oct-2004
# Posted on: 15-Jun-2011 18:04:32   

Is UnitOfWork2 supposed to be serializable for use with WCF? Based on comments in old threads, it was planned to be implemented for version 3 but I can't find anything in the docs that addresses UnitOfWork specifically.

When I try to send a UnitOfWork2 (with version 3.1), I get deserialization errors for the various lists contained within the uow. For example:

System.ServiceModel.FaultException : The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter uow. The InnerException message was 'Error in line 1 position 30173. Element ':_deleteEntitiesDirectlyCalls' contains data from a type that maps to the name 'System.Collections.Generic:List`1'. The deserializer has no knowledge of any type that maps to this name. Consider changing the implementation of the ResolveName method on your DataContractResolver to return a non-null value for name 'List`1' and namespace 'System.Collections.Generic'.'.  Please see InnerException for more details.

I can add all of these lists as ServiceKnownTypes, except that three of the classes for which there are lists are internal. That is, I can add

[ServiceKnownType(typeof(System.Collections.Generic.List<SD.LLBLGen.Pro.ORMSupportClasses.UnitOfWorkBlockType>))]

but not

[ServiceKnownType(typeof(System.Collections.Generic.List<SD.LLBLGen.Pro.ORMSupportClasses.UnitOfWorkCallBackElement2>))]

With some extra work I can add them through reflection, but before I do that I'm wondering if I'm missing something obvious, or if this is even meant to work. Should I be looking at a different approach than sending a UnitOfWork?

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 16-Jun-2011 07:47:14   

AFAIK, Uow is only doable through remoting and you can't use it directly on WCF serialization. I don't see any relevant change on v3.x about this. I have to check whether this is true or not.

David Elizondo | LLBLGen Support Team
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 16-Jun-2011 11:40:39   

We didn't implement it in v3, because it's actually an antipattern: the service is to be an application on its own, not a tier which you communicate with on a low-level basis.

However, we do know that people like to use services on a REST level even though it will cause a lot of 'chatty-ness'. We have planned to implement it in a future version, but when is not certain.

Frans Bouma | Lead developer LLBLGen Pro
ww
User
Posts: 83
Joined: 01-Oct-2004
# Posted on: 16-Jun-2011 16:24:41   

So is everyone using DTOs rather than sending entities back and forth? I have .NET applications at both ends, which can share assemblies, so there doesn't seem to be much benefit for me in adding a DTO layer vs just sending over the entities.

On the way back, I assumed that sending a UnitOfWork back, containing only the entities to be updated, would be better than sending back an entire object graph where many of the entities won't have changed. Or am I misunderstanding this? I haven't looked at it in depth yet.

MTrinder
User
Posts: 1461
Joined: 08-Oct-2008
# Posted on: 16-Jun-2011 20:46:05   

No you have understood it correctly - however there is no reason why you have to send back a UOW - just send back an array of the modified entities, and use a transaction on the other side of the service.

Matt

ww
User
Posts: 83
Joined: 01-Oct-2004
# Posted on: 17-Jun-2011 18:37:03   

OK. Thanks for the info.