Multi profile support

[Marvin-Brouwer]

So we'd like to support multiple profiles for when you have one POCO but multiple API endpoint that may need different fields or even just a different naming convention.
The difficult part is how to design that, Currently we have 3 proposals:

Keep in mind that these are just suggestions and not the final approach, this is just to illustrate the general approach but the eventual code may change.

1: Overloads

Having an overload for each method where you can provide a profile when serializing.

// Normal
_ = serializer.Serialize(example);
_ = serializer.Deserialize<TExample>("...");
// With specific profile
_ = serializer.Serialize(example, typeof(ExampleProfile));
_ = serializer.Deserialize<TExample>("...", typeof(ExampleProfile));

Pros:

• Apparent in line there's another profile being used

Cons:

• Decentralized approach
• Possible duplication

2: Factory approach

Having a named factory in the DI setup where you can reference the applicable profiles.

// Normal
container.RegisterProfiles<INameSpaceKey>();
// With specific profile
container.RegisterProfiles<INameSpaceKey2>("name1");
// A way to override when a namespace has more than one profile for a type
container.RegisterProfiles("name2", c => {
  c.AddProfile<TSpecificProfile>();
});

public class SomeService {

   private IJsonSerializer _jsonSerializer;

   public SomeService(IJsonSerializerFactory serializerFactory) {
      _jsonSerializer = serializerFactory.Get("name3");
   }
}

Pros:

• No additional API for usage
• Centralized approach

Cons

• Not apparent inline that it's using a specific profile

3: Fluent approach

Adding a property to the serializer to return a new instance of the serializer that only supports that given profile.

// Normal
_ = serializer.Serialize(example);
_ = serializer.Deserialize<TExample>("...");
// With specific profile
_ = serializer
    .WithProfile<ExampleProfile>()
    .Serialize(example);
_ = serializer
    .WithProfile<ExampleProfile>()
    .Deserialize<TExample>("...");

Pros:

• Apparent in line there's another profile being used

Cons

• Decentralized approach
• Not really supported by the DI framework, but is that really a problem?
• Allocating another complete serializer for just a profile switch.
  However, perhaps this is doable with a wrapper that overloads a Func<> which is responsible for looking up the profiles?