Programming API redesign [Closed]

[Marvin-Brouwer]

Currently, the library requires IOC injection.
This is primarily due to the fact that we need to compile and resolve the profiles to know how and what to (de)serialize.
This is done centrally on application startup before registering the profiles in the IOC container.

If we consider that we move towards source-generators to generate the concrete implementation of the profiles, the need to have injection becomes less obvious.
The source generator can convert the expression in the profile into a concrete implementation on build time and then you can just point to the profile when you need it.
Solving a couple of issues:

• Startup time is reduced
• Having multiple profiles for the same type now no longer resolves to the first one that's found since you'll reference it directly, removing the need for something like #48
  Perhaps it even may make sense to generate a default implementation that iterates over the profiles created by a source generator.
• IOC may not be necessary

Regardless of the source generator part, the computation time of building a concrete mapping of the profiles isn't all that heavy. So it may just make sense to redesign the API anyway.
Having a serializer that's statically available (like Newtonsoft.Json and System.Text.Json) makes sense in that it's more accessible to use in places where it's necessary.
For example, If you have an API client that makes an HTTP request and deserializes the response, with Newtonsoft.Json you can just call an extension method on the response without the need for injection.
You can argue that you can't mock the serialization. But usually, the API client isn't usable without the serialized result anyway and your mock ends up either calling a simpler serializer or returning a string literal/mock object which is a lot of clutter for functionality that should be predictable.
Another argument against having DI would be that not every application needs DI. In that scenario the library would not be usable.

So what are the options?

Option 1, don't change

Use source generators to create the concrete profiles but keep the IOC

Option 2, remove DI necessity with the source generator change

When rebuilding the library to support source generators is the best time to change the API

Option 3, remove DI necessity immediately

Redesign the API first, keeping in mind how the source generators will work but do it at runtime for now.

---

Please comment a summary why you chose the option.

[Marvin-Brouwer]

In addition to either removing DI or making it optional we can move the responsibility of the serializing to the concrete profile implementation.
Where you can have a single ISerializer and based on the profile passed it'll generate XML or JSON.

[Marvin-Brouwer]

This question has also been asked in person to a few people and in a discord channel.
In this discord channel we got a new insight which is a vastly better approach.

The question asked was whether it was worth the effort to support IOC even when it's no longer required functionally.
To which @manio143 answered:

I would say yes, because not every project needs DI and this could simplify usage of your serializer. But you should also consider the amount of work necessary and if moving away from DI would lower the extensibility of your serializers (sometimes you might need runtime configuration as opposed to compile time configuration, but I don't know exactly how your library is structured to be more insightful).

This is a very useful insight. Even though it makes sense to still support IOC, some people also just don't have the necessity for having IOC. Hence, we actually should support BOTH.

[Marvin-Brouwer]

Because of the lack of input ant he new insights, a new issue has been created: #157.

This discussion will be closed.