I was wondering if any thought has gone into generating an interface to go
along with the generated data classes from a proto.
And if it had been considered were there any reasons to not do it?
Quick sketch of my current situation:
I have a project that has a complex and messy internal data structure
(assume for now its too expensive to refactor).
On top of this I created an interface that already bears semblance to a
.proto model we use. And an implementation of this interface which has a
reference to an internal object and 'transmutes' the data from the internal
model to the external format. So aside from the reference to the internal
object, no data is held by the interface implementation. It basically acts
as an adapter.
The implemented getters/setters allow the transmutation of internal data
structures to 'external' structures
I am now however looking into simply generating this interface and part of
the implementation to allow this model to be exported easily, while still
having a clean API, which would (in time) also allow for code written
against the generated API (also C++/python) to be portable.
For this I've been hacking away a bit at the C# proto generation code in an
effort to generate something that would fit into the design below:
What I've done so far
- Added a mirror of csharp_reflection_class as
csharp_reflection_interface (ReflectionInterfaceGenerator) to generate
what I would like my interface to look like
- Added interface-ended generation options to protoc cli
- Changed/added namespaces to use in generation (because in my case, the
interface is in a different namespace than the implementation)
- Added a way to extract (ie not generate) property get;set; (similar to
how https://silentorbit.com/protobuf/ generates from proto), the developer
will need to implement these themselves, but having the interface enforces
Now there are a number of open questions/issues that I thought proto
devs/experienced C# developers might be able to weigh in.
1. In various areas, the package name defined in the .proto is used as a
way to create the namespace, types etc which aren't even overwritten by
the --csharp_opt=base_namespace=... option. and it (seems) requires a C#
specific option in the .proto (option csharp_namespace =...) Is this
something I should definitely not overwrite/force, or can I freely change
namespaces of generated files without problems in later
2. Proto doesn't actively support inheritance causing each C# object to
hold derived object instances. This is currently all generated out, but for
any OO language it doesn't make any sense to have this in a design. But
these are still generated as-is. I've considered custom proto markup
extensions to mark these types as being derived to ignore them in
generation of the interface (not implementation), but I'm unsure whether
there are better ways to go about this.
3. The implementation explicitly generates private fields for each
property and some code (Equals / GetHash etc) use these fields directly.
For my purpose however I don't need/want these fields, instead the
implemented accessors should be used. Would this cause any problems with
the generated code (after moving all field usage to accessor usage)?
Are there any alternative solutions that I've missed, would any of this
work be in any way/shape form be useful for the Proto C# generation
Thoughts, ideas, suggestions?
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.