After the callbacks, the next extensibility point on the list for serialization are the surrogates. This will be a short post, since the surrogate idea is simple (once you understand it) and there is some good documentation on MSDN about this issue, so I don’t think I need to repeat it here. Surrogates have been around for a while, even before WCF, and their idea is simple: replacing one type A which is part of an object graph to be serialized with another type B (the “surrogate”). The main reasons why we’d want to do that are either because the type A isn’t serializable at all, or because it doesn’t have a serialization format which we want, so we use a surrogate to change it. The first case is straightforward – sometimes you have a type from a 3rd party or a legacy library which cannot be modified to accommodate serialization, but it’s part of the object graph which you want to exchange between client and server. One possible solution is to replicate the graph in Data Transfer Objects (DTO) which only contain the data which needs to be serialized. Sometimes, however, this may not be the best approach (too many types, high cost to convert between DTOs and objects with business logic, etc.), so a surrogate can be an way out. The second case (wanting to change the serialization format) doesn’t happen very often, but there are some scenarios where users want to change the way a type is serialized. Before WCF was released, the way to implement surrogates was by using the ISurrogateSelector and ISerializationSurrogate interfaces.. Most of the previous “serializers” (including the BinaryFormatter and the SoapFormatter) supported it via the IFormatter interface. When the formatters were serializing an object graph, they’d search in their “surrogate chain” to see if any surrogate was present to deal with each type in the graph; if this was the case, then it would use the surrogate to serialize / deserialize the objects instead of the object itself. Read more: Carlos' blog
QR:
QR: