Serialization roadmap

[rockfordlhotka]

CSLA has been moving away from BinaryFormatter (and NDCS) for years. Microsoft is planning to obsolete BinaryFormatter in .NET 9, so I've opened a backlog issue to remove the requirement for using the Serializable attribute: #3687

I'd like to have a discussion about extensibility and serialization.

CSLA still has all the configuration to allow someone to create a different serializer from MobileFormatter if they desired. Over the years MobileFormatter has become quite good, but every now and then someone expresses the desire to create something better - and that would be wonderful!

The thing about any CSLA serializer/formatter is that it must be full fidelity. Meaning that it either needs to serialize at the field level like BinaryFormatter (not at the property level), or it needs to work with the CSLA field manager and other concepts to serialize logical fields. It also needs to handle duplicate references to a single object instance, such that when the graph is deserialized the shape of the graph is identical.

Most JSON and XML serializers/formatters don't do these things and so aren't useful.

What I'm saying, is that creating a serializer is hard.

Nonetheless, and here's my question, I wonder if CSLA should define a replacement attribute for Serializable to make it easy to identify serializable types - it would be used by MobileFormatter and could be used by anyone else's serializer in the future.

Having an attribute "owned" by CSLA instead of .NET would be a good thing in some ways.

However, there's also an argument to be made that each serializer should define its own attribute (if it needs one). So if you want to use this other serializer, you'd go through all your classes and decorate them with the serializer's attribute.

From a maintainability perspective this could go either way, so I'm interested in people's thoughts.

[ossendorf-at-hoelscher]

I personally don't like marker attributes for this kind of stuff. I see the problem with types you don't have control over but are simpel enough to just be serialized. But because you can't add the attribute to the type you have to work around that limitation to get it work.
I think the current serializers (e.g. Newtonsoft, STJ) don't need those anymore exactly for that reason. It would impose a heavy restriction on usage.
Another way would be to "out source" those definitions like the definitions you have to define for e.g. FluentValidations or AutoMappers Profiles.

I argue against marker attributes because I think the restriction is greater than the benefit.

Ps: We should not forget #3363 #3711 #2531 #2523 #2148

[rockfordlhotka]

Oh yes, anyone writing a new serializer will need to figure out how to match the features provided by MobileFormatter, including the upcoming concept of providing custom serializers on a per-type basis.

[rockfordlhotka]

So my question wasn't entirely hypothetical 😄

https://github.com/JasonBock/CslaGeneratorSerialization

It turns out that source generators are most efficient if they can drive off interfaces.

So to refine my question, should the "serializable" interface be in CSLA, or in a serializer?

[ossendorf-at-hoelscher]

They are not only efficient but also enable AOT. But the source gen suffers from the same problem I described with marker attributes.
It only works when you have control over all types used for serialization.

Question other way around: How will CSLA serialize anything when there is not interface to "connect" into CSLA to tell it serialize this (not how).

[rockfordlhotka]

The thing is, that CSLA types are "special", and most formatters simply can't provide the behaviors necessary to serialize and deserialize object graphs the way CSLA requires.

The list is short:

• BinaryFormatter
• NDCS
• Newtonsoft (with specific configuration)
• MobileFormatter

As far as I know, that's the list.

And the first three are all deprecated and/or totally obsolete.

[ossendorf-at-hoelscher]

It's sad that Newtonsoft seems to be dead even though STJ can't replace it :(

[JasonBock]

The main reason why the SG approach is more efficient (or at least seems to be) is because I can interact with the stream with known types directly. That is, I don't have to do as much with Reflection, nor do I need to store "known type" enumeration values for each field. There's other reasons, but those definitely come into play. And yes, being a compile-time thing, there's natural wins with that over runtime Reflection strategies, especially as it pertains to AOT.

With SGs, you really want to target attributes if at all possible - hence the usage of ForAttributeWithMetadataName(). Sometimes, that's not possible, but there are compilation pipeline perf wins with that approach. It may turn out for my SG that having my own attribute - call it [GeneratorSerializable] for lack of a better name - is what CSLA types should be marked with so I can find them and gen the correct serialization code for them. I think that with CSLA itself, using [Serializable] is becoming a minor paper cut that happens with every type definition that arguably really doesn't need to be there.

One other point - @rockfordlhotka and I have talked about letting developer define their own strategies to handle any arbitrary type that is defined with a PropertyInfo<>-based backing field. Right now, both MobileFormatter and my SG handle the "common" cases, like numbers, strings, etc. But an arbitrary struct will cause both serialization engines to barf :). I added this issue to my SG as a design idea to allow developers to register support for types in an IoC container, which would then solve this issue (I think).

FWIW, I would vote for removing the requirement of [Serializable] being on every BO, and let the serialization engine in play define its rules in terms of what is required for CSLA graphs to work successfully with their strategy.

[swegele]

I like the idea of separate/distinct attribute which gives you the benefits mentioned and also distinguishes this from old .net serializer stuff.