Reputation: 7294
I am wondering what would be the best approach in a WPF (possibly MVVM) based application, where the data exchange with the remote devices is made through Protocol-buffers (if conveniently applies).
WPF is strongly based on observability, as well as the mutability of the underlying model/viewmodel, with DPs and INotify* interfaces. Is it fighting against the protocol-buffer approach of create/mutate POCO's?
The typical context is having a WPF client application, connected via TCP/IP to an embedded device running Linux. Basically, I'm evaluating pros/cons of several solutions in order to find out the best one.
Thank you in advance.
Upvotes: 1
Views: 891
Reputation: 1063338
Your key points seem to be about mutability and observability.
The google protobuf API is indeed largely immutable and won't love WPF very much; however, you also mention protobuf-net, which is not that pattern, and adopts instead standard .NET idioms.
A protobuf-net model can be any standard model you want. If you want it to have notification events... have notification events. It won't mind. I can't remember 100%, but if you are working from a .proto file, I believe there is a switch to have to codegen add notification events automatically, but .proto is entirely optional with protobuf-net.
The output from protobuf-net should be entirely interchangeable with any other implementation for your linux device. One option there would be Mono/protobuf-net, but you could use the "standard" implementations too.
Upvotes: 0
Reputation: 178770
WPF should have zero bearing on this because your data exchange should be separated into a separate, UI-agnostic layer. Your service layer can return non-GPB objects if necessary (or returns interfaces that your GPB objects implement via partial classes), and your view model layer provides yet another layer of insulation.
Upvotes: 3