11.4 Implicit Serialization

Not all serialization and deserialization is explicit. Consider the following set of serializable classes:

 [Serializable] public sealed class Person {   public string Name;   public int Age; }    [Serializable] public sealed class Team {   public string Name;   public Person[ ] Players; } 

Serializing an instance of Team causes the embedded array of Person instances to implicitly be serialized.

Additionally, types can be serialized as part of method invocations. For example, imagine a function that merges two Team s using some complex algorithm, declared as follows :

 public Team MergeTeams(Team teamOne, Team teamTwo) {...} 

If instances of the type containing this method were always created and then used from within the same AppDomain , the calling code and the method itself could share the Team references. However, if we want to invoke this method from outside the AppDomain it was created in (or even from off the machine it was created on), the method invocation needs to be remoted across the AppDomain machine boundary.

While the remoting process and the supporting infrastructure in the Framework is rich, powerful, and complex, this chapter doesn't delve into remoting. However, it is helpful to understand that one of the steps in remoting involves turning a method call into a pair of request and response messages that can be transmitted across AppDomain or machine boundaries. If the MergeTeams method is remoted, the teamOne and teamTwo parameters are implicitly serialized into the request message by the same serialization infrastructure we used explicitly earlier in the chapter, and the resulting merged Team instance is implicitly serialized into the response message on method completion.