.Net Core remoting replacement compatible with LLBLGen object graph serialization?

Posts   
 
    
GizmoTN76
User
Posts: 36
Joined: 22-Oct-2007
# Posted on: 06-Jan-2022 21:54:58   

We've been using llblgen in our product since 2008 and have started to investigate our options for porting things to .NET Core but we've been puzzling over how to get around the fact that they gutted .net remoting out of the runtime.

Currently the way our architecture is laid out we essentially have 2 modes, local in which the client talks directly to the db, and remote where it talks via remoting to perform dal related chores on the server. Our implementation of that essentially wraps/proxies most of the methods off the DataAccessAdapter and exposes them over remoting such that we only had to expose that as a generic interface to handle all our data access instead of special purpose methods per entity type/use case. It allowed our code to be relatively simple as we could flip back and forth between local and remote dals with the flip of a switch for a dal layer factory.

Perhaps I'm missing something (I really hope I am) but I'm not seeing any sort of comparable RPC to replace remoting with. Ideally we could just swap out the remoting proxy another form of generic rpc which would allow us to call things like FetchEntityCollection, CommitUnitOfWork etc. on the server generically but those methods obviously require a full serialized set of .net types like EntityCollections, uows, prefetch paths, etc.

Is there any relatively clean way to pass/serialize object types like that across the wire in .net core such that we can just replace remoting with another technology? It would obviously be nice to avoid a full rewrite of our data access for a rather large codebase if it can be at all avoided.

Thanks for any help/ideas.

Scott

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 07-Jan-2022 09:05:03   

To my knowledge Microsoft has more or less abandoned the BinaryFormatter as it's too insecure. There is some code in .net core for backwards compatibility but that's about it. A lot of types aren't serializable so you won't get the same behavior back as you got on .net framework.

They more or less want you to write services where you expose an API which is used by a thin client. This is also the reason why we added the derived model feature so you can easily create the DTOs and generate the code to e.g. update entities from DTOs which are send to the service. Moving your code to .net core / .net 6 therefore will have to include a rewrite of that crucial part that relies on binaryformatter.

The alternative route of using json (basically using the ISerializable interfaces we implement to convert data to json) could work too but might be pretty slow.

Frans Bouma | Lead developer LLBLGen Pro
dodyg
User
Posts: 42
Joined: 04-Dec-2014
# Posted on: 30-Jan-2022 06:00:32   

GizmoTN76 wrote:

Perhaps I'm missing something (I really hope I am) but I'm not seeing any sort of comparable RPC to replace remoting with. Ideally we could just swap out the remoting proxy another form of generic rpc which would allow us to call things like FetchEntityCollection, CommitUnitOfWork etc. on the server generically but those methods obviously require a full serialized set of .net types like EntityCollections, uows, prefetch paths, etc.

You should consider using gRPC to replace remoting. I would investigate the viability of generating ProtoBuffer contract using LLBLGen Templates.