C# 强类型等效于泛型类型，其中 SomeClass<t, v> 和 SomeClass<v, t> 是相同的</v,></t,>

Question

TL;DR : In C#, what is a good way to create DTOs for serialization/deserialization, wherein different, strongly-typed properties may be independently present or absent in different contexts, but with the DTOs themselves being strongly-typed and non-dynamic, and without manually creating a new class for each scenario ?

---

I'm running into what I think is a weak point in C#, but want to see if there's some way around this:

For a current project, I'm going to be having multiple microservices communicating with each other, and each microservice will need zero or more things passed in through the body of an HTTP REST request. Some microservices will need the same sets of data, and some microservices will need to different sets.

The stock way to do this would be to manually create a new DTO class for every scenario, then use those DTO types in parameters: [FromBody] SomeDtoType someData .

However there's a problem in this case: I want to mix and match these different sets of data as desired, where each microservice method can just kind of pick and choose which sets it desires; and I want to do this without manually creating a separate class in each individual case.

So for example, imagine I have something like this:

[Flags]
public enum InvocationArgTypes
{
    None = 0,
    Webhook = 1,
    DataSource = 2,
    ...
}

---

[DataContract(Name = "Webhook")]
public class WebhookDto
{
    ...
}

---

[DataContract(Name = "DataSource")]
public class DataSourceDto
{
    ...
}

This then is what I want to avoid :

1. InvocationArgTypes.None --> null

2. InvocationArgTypes.Webhook --> WebhookDto

3. InvocationArgTypes.DataSource --> DataSourceDto

4. InvocationArgTypes.Webhook & InvocationArgTypes.DataSource --> WebhookDataSourceHybridDto

5. ...

One of the main reasons is that, as the list InvocationArgTypes grows, having to account for each individual case of 2, 3, ..., n flags and manually create classes for every case isn't just time-consuming; it pollutes the type system with many awkwardly named classes, such as Type1Type2Type3Type4HybridDto .

Now for the million-dollar question: Why not just use generics? Because SomeGeneric<Type1, Type2> and SomeGeneric<Type2, Type1> are not the same. In particular, it would be easy for two services to look at the same exact flags in that enum and accidentally order the same generic parameters differently.

Normally that type of thing points to using dynamic types...but I really want to avoid that if possible.

So does C# have a good solution to this problem? If so, what is it? Or do I really need to settle on one of the options above?

Please note: It is acceptable in this case to always wrap every body in an overall, "grand DTO type", which contains all of the 0 or more sets of data specified by the flags enum as properties. In other words, whether no flags are set or every flag is set, it is okay, if needed, to still use the same "grand DTO type" as a wrapper, if there's a good, clean way to do so.

Answer 1

This seems like an incredibly deep (and interesting,) question. and I'm not familiar enough with microservices to feel fully confident in offering a practical solution, However, I notice that you didn't mention conversion operators as one of your proposed solutions, so I need to use the space of this answer to share with you what's effectively an elongated comment on this topic.

Observe the below little toy program. This shows the use of an implicit operator, which I learned of in this answer recently. The operator converts a generic type by flipping the generic parameters:

using System;

public class Program
{
    public static void Main()
    {
        GenericDto<string, int> dto = new GenericDto<string, int>("Hello world", 42);
        StringIntUser siu = new StringIntUser();
        IntStringUser isu = new IntStringUser();
        Console.WriteLine(siu.print(dto));
        Console.WriteLine(isu.print(dto));
    }
}

class IntStringUser
{
    public string print(GenericDto<int, string> dto)
    {
        return string.Format("Int {0} is paired with string {1}", dto._t1, dto._t2);
    }
}

class StringIntUser
{
    public string print(GenericDto<string, int> dto)
    {
        return string.Format("String {0} is paired with int {1}", dto._t1, dto._t2);
    }
}

class GenericDto<T1, T2>
{
  public T1 _t1;
  public T2 _t2;  
  public GenericDto(T1 t1, T2 t2)
  {
    _t1 = t1; _t2 = t2;
  }
  public static implicit operator GenericDto<T1, T2>(GenericDto<T2, T1> dto) => new GenericDto<T1, T2>(dto._t2, dto._t1);
}

Now, as I mentioned in the preamble, I have no idea how practical this is for your use case. I can't really see how you're using the different DTOs. In particular, I see the following limitations:

• All the data needed to construct an instance of the generic class must be publicily available, so that we can re-order it.
• The number of implicit operators you need to define grows faster than exponentially with the number of generic parameters (which I presume correspond to members of your enum). Specifically, there are n! (n factorial ) different orderings of n parameters, so we'd need to write that many conversion functions. That's a lot of functions to write. For just 10 generic params, we'd need around three and a half million functions. However, I have a vague idea that there might be a clever hack using composition. Only 50% confident. Not going to try anything until I get more feedback on your use case.
• My very limited understanding of microservices is that they're all separate little programs communicating to each other via text. So I'm wondering would the implicit operator need to be defined repeatedly in each microservice? Would this be a problem?

Would you mind fleshing out your use case in the question? Specifically, could you show and end to end use case? Is there any way you can disentangle the question form microservices and DTOs specifically or are they an essential component? Well, I'm assuming microservices can't be disentangled, based on this comment:

...And it has to play nice with stock, run-of-the-mill serialization and deserialization: :)