2

In protobuf-net,
Is there a plan to add support for attribute-less POCOs, to avoid the property indexes (ProtoContact) ?

I have not problem to add indexes for each property on DTO.

I create the DTOs automatically with my utility and there is a configuration flag for protobuf members.

The problem is that using RESTful services with ServiceStack,

I share to customers (who work in .Net) 2 assemblies,

  1. the model without any dependencies, nor ServiceStack (not IReturn), nor protobuf-net.

  2. The client.requests, which is a thin wrapper to actual service calls, with some validation,

    error handling, etc. Essentially are simplified calls for every service.

    This assembly has dependencies on ServiceStack client and Protobuf-net.

But the model is dependency-free, because customers can use it, directly in their business layer.

In this case, I have problem with protobuf-net, not with ServiceStack as IReturn is not mandatory.

Is there any solution about that, to avoid add protobuf indexers ?

Update: thanks to Mark Gravell, his answer here and in previous related question

the solution is the alternative inline attributes,

[XmlType]/[XmlElement(Order=key)] using only System.Xml,

or [DataContract]/[DataMember(Order=key)] using System.Runtime.Serialization.

So the model is dependency free, without references to protobuf-net.

I should have read better about.

         [XmlType("Person")]
        public class Person
        {
          [XmlElement(Order = 1)]
          public string Name { get; set; }

          [XmlElement( Order = 2)]
          public string Address { get; set; }
       }

thanks

Community
  • 1
  • 1
stefan2410
  • 1,931
  • 2
  • 16
  • 21

1 Answers1

2

2 options present themselves:

  • if the generated code is a partial class, you can create a second partial class file for the same type, and add the attributes there - this is then part of the same type; in particular, note that [ProtoPartialMember(...)] can be added to a type (multiple times), but describes a member; or if you want less maintenance, [ProtoContract(ImplicitFields=ImplicitFields.AllPublic)] can be used to let the model take control of the rules (but please read the intellisense remarks on ImplicitFields before doing this)
  • you can configure the type at runtime, using whatever rules you want, via RuntimeTypeModel:

    var metaType = RuntimeTypeModel.Default.Add(yourType, false);
    // TODO: some reflection that decides what members you want to serialize
    // and as what keys
    foreach(...)
        metaType.Add(member, key);
    
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • I would prefer first option, as I can generate the code. Question: the second option has reflection overhead ? – stefan2410 Dec 11 '13 at 14:26
  • @stefan2410 only when you configure the model, which you would only do once – Marc Gravell Dec 11 '13 at 14:26
  • Also, more important question about the partial class. Do you mean that in client side, I will give both, the dependency free model assembly for customer integration and the model with attributes together with the client.requests assembly for the actual service calls ? Or attributes don't required in client side. – stefan2410 Dec 11 '13 at 14:28
  • @stefan2410 I don't think I mean either of those things; what I am saying is that if, by whatever mechanism, you have some generated `partial` classes, then *one option* is to add the attributes by using `partial class` in a second file. Now, as per the second bullet above, indeed it is true that attributes are not required - they are simply more convenient that configuring the model via code – Marc Gravell Dec 11 '13 at 14:30
  • I was not clear before. I have understood the 2 options. The second option is not viable for me, because the DTOs are predefined with customers ( CRUD or query results). To serialize them in code, it seems error-prone. What I asked above is that in first option, (maybe naive question) the client side code needs the keys to deserialize the buffer? I think yes . In this case, with the partial class, I can give to customer a dependency free model for further integration in its system, and a model assembly with proto-keys for the actual client request. Is it correct? – stefan2410 Dec 11 '13 at 14:56
  • @stefan2410 if all the client gets is C# classes, then that won't work well - it needs more information; if they get a dll, there may be options. What do they get? – Marc Gravell Dec 11 '13 at 15:22
  • they get 2 dll's. First with model only (C# classes) the second with client requests (wrappers of service calls). I can include in the second dll, the partial class with attributes. Also, according to your [answer](http://stackoverflow.com/a/8179429/2103764) can I use for attributes the [XmlType]/[XmlElement(Order=key)], as you write, so avoid dependency in protobuf ? – stefan2410 Dec 11 '13 at 15:32
  • @stefan2410 yes, you can use alternative attributes; either the XmlSerializer ones (as cited) or the WCF/DataContractSerializer ones – Marc Gravell Dec 11 '13 at 15:55
  • yes, I should have read better, about the alternative attributes. In this case, I have a dependency free model. thank you. – stefan2410 Dec 11 '13 at 16:16