End of the road for BinaryFormatter? #2567
-
While working on CSLA 6 I have encountered an issue where dependency injection conflicts with distributed computing. Specifically, when an object graph deserializes, some of the types in that graph need to have local services injected for use (most often the ApplicationContext). When you ask the data portal for a BusinessBase or ReadOnlyBase subclass, the local data portal creates the requested instance, uses dependency injection to inject required services, initializes the instance by calling your When a remote data portal does that, the resulting object is serialized from the server back to the client. The services injected on the server don't (and can't) come with - they need to be "reinjected" during deserialization. This is possible with MobileFormatter, because it is part of CSLA. BinaryFormatter (and NDCS) are (a) not extensible like this; (b) obsolete and removed in .NET 5 and 6. So I'm proposing, especially since Microsoft is dropping them, that CSLA 6 on all platforms drop them, leaving only MobileFormatter (or you can supply a custom formatter that has the same behaviors, now including support for DI). Thoughts? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Although I'm using BF right now, I've been preparing to move to MF. I've set up 2 DI containers. One on the server and one on the client. The client registers the WPF screens for PRISM and the server does a buildup of the container for use on its side. I think there will be some testing coming up, which is not a problem. I vote for dropping both BF and NDCS. We can always revisit this once the upgrade is complete if needed. |
Beta Was this translation helpful? Give feedback.
-
I've spent quite a few hours over the past couple days on this, and have come to the conclusion that MF is the only way forward. I almost have everything working now, where MF deserializes the object graph and re-establishes the ApplicationContext for use by the deserialized graph. I'm personally quite comfortable with dropping BF/NDCS support, because Microsoft has eliminated them from .NET itself going forward. Also, for several years now MF has been the better option anyway, given all the work put into it by members of this community. |
Beta Was this translation helpful? Give feedback.
I've spent quite a few hours over the past couple days on this, and have come to the conclusion that MF is the only way forward. I almost have everything working now, where MF deserializes the object graph and re-establishes the ApplicationContext for use by the deserialized graph.
I'm personally quite comfortable with dropping BF/NDCS support, because Microsoft has eliminated them from .NET itself going forward. Also, for several years now MF has been the better option anyway, given all the work put into it by members of this community.