I read some microsoft articles.They explained that WCF uses DataContractSerializer for serialization.But the articles did not explain why DataContractSerializer preferred over
XmlSerialization.Can anyone give me the additional information?
Here is an article with a comparison.
Key section:
XmlSerializer
Advantages:
Opt-out rather than opt-in properties to serialize. This mean you don’t have to specify each and every property to serialize, only those you don’t wan to serialize2. Full control over how a property is serialized including it it should be a node or an attribute
Supports more of the XSD standard
Disadvantages:
Can only serialize properties
Properties must be public
Properties must have a get and a set which can result in some awkward design
Supports a narrower set of types
Cannot understand the DataContractAttribute and will not serialize it unless there is a SerializableAttribute too
DataContractSerializer
Advantages:
Opt-in rather than opt-out properties to serialize. This mean you specify what you want serialize
Because it is opt in you can serialize not only properties, but also fields. You can even serialize non-public members such as private or protected members. And you dont need a set on a property either (however without a setter you can serialize, but not deserialize)
Is about 10% faster than XmlSerializer to serialize the data because since you don’t have full control over how it is serialize, there is a lot that can be done to optimize the serialization/deserialization process.
Can understand the SerializableAttribute and know that it needs to be serialized
More options and control over KnownTypes
Disadvantages:
No control over how the object is serialized outside of setting the name and the order
Related
A class that has the [DataContract] attribute, is it not automatically serialized?
If not, is it a requirement to use the [Serializable] attribute (or inherit from ISerialize)?
I ask this because I have old code from a previous project that apparently the [DataContract] classes do not mention anything, explicitly, about serialization.
The ultimate question:
I want a WCF operation (method) to return a DataContract class.
Does the method have to explicitly serialize the class before returning it, or is it automatically serialized? I always thought it would be the latter.
Thanks!
No, [Serializable] is not necessary on a data contract. It is also not necessary for XML Serialization.
There's a few options for serialization in .NET. SerializableAttribute and ISerializable go back to the beginning and are used by the BinaryFormatter, SoapFormatter, etc.
DataContractSerializer, being relatively new, can support objects that define their serialization ability with SerializableAttribute, but it's not necessary. If you are just serializing the object using DataContractSerializer then using the data contract attributes is all you need to do.
Obviously the members you mark as serializable must also be of serializable types.
For more information, see Types Supported by the Data Contract Serializer on MSDN.
Just to add on to this, DataContractSerializer supports far more than just DataContract types. See this excellent blog post for a detailed walk-through of the entire universe of types supported by DataContractSerializer: http://blogs.msdn.com/b/sowmy/archive/2006/02/22/536747.aspx
Can anyone please elabortae me the reasons why should I use Data Contract Serializer
while we have XML/Binary serializer already there in .Net ?
This is a site i found when i was looking into the same issue.
You should check this out
Quoting from the same link mentioned above:
Advantages of DataContractSerializer over XMLSerializer
Opt-in rather than opt-out properties to serialize.
Because it is opt in you can serialize not only properties, but also fields. You can even serialize non-public members such as private or protected members. And you dont need a set on a property either (however without a setter you can serialize, but not deserialize)
Is about 10% faster than XmlSerializer to serialize the data because since you don’t have full control over how it is serialize, there is a lot that can be done to optimize the serialization/deserialization process.
Can understand the SerializableAttribute and know that it needs to be serialized
More options and control over KnownTypes
Hope it helps!
One more HUGE advantage; DataContract serialization allows for interop between any two classes that implement the same DataContract. This is what allows WCF to generate the data classes for you automatically when you reference a WCF service. You can also "hack" this process by referencing a published DataContract in a new user-developed class (or two or three); You can then transfer data between instances of these classes, and any other new ones you create, via serialization. This is also possible but much more difficult with XML serialization, and impossible with binary serialization.
XmlSerialization creates a serializer proxy for each class. The proxy resides in a different assembly so it can serialize only public fields.
DataContract serialization can serialize private fields too. Does it mean it uses reflection? Isn't it slower than using a proxy (except for the first time)?
This protobuf-net page shows the performance of DataContractSerializer to be significantly better than XmlSerializer. Of course, you should always test with your own data, but if you are looking to replace XmlSerializer, you will most likely find DataContractSerializer to be a performance improvement.
I'm not sure how DataContractSerializer is implemented internally, but generally serializers are highly optimized. This is especially true for DataContractSerializer since it is a big part of the performance picture for WCF. It is not uncommon for a serializer to generate MSIL code on the fly. When this is done, DynamicMethod allows you to (surprisingly!) bypass visibility checks (see MSDN), so it is possible to access private fields without reflection.
From MSDN:
Given sufficient security permissions,
a serialization engine implemented
using dynamic methods can access
private and protected data to enable
serialization of objects not authored
by the engine creator.
I am working with WCF .NET 3.5 SP1 and have read that one does NOT have to decorate their Entities/Collections with such things as [DataMember], [DataConract], and/or [Serializable]? What is the best way to go? What have you all encountered?
I am on 3.5 SP1.
See Using Data Contracts.
New complex types that you create must
have a data contract defined for them
to be serializable. By default, the
DataContractSerializer infers the data
contract and serializes all publicly
visible types. All public read/write
properties and fields of the type are
serialized. You can opt out members
from serialization by using the
IgnoreDataMemberAttribute. You can
also explicitly create a data contract
by using DataContractAttribute and
DataMemberAttribute attributes. This
is normally done by applying the
DataContractAttribute attribute to the
type. This attribute can be applied to
classes, structures, and enumerations.
The DataMemberAttribute attribute must
then be applied to each member of the
data contract type to indicate that it
is a data member, that is, it should
be serialized. For more information,
see Serializable Types.
Like #Terry said, it's probably better to proactively declare which properties you want to expose. This way you could future proof your code from unintentionally exposing fields when the base class adds a public property in the future.
I'm of the opinion that it won't hurt to proactively express you intent to use the class as a DataContract. I would guess that a class that isn't serializable still won't be useful as a DataContract in SP1... :)
how does Serialization of objects works? How object got deserialized and a instance is created from serialized date without a call to any constructor?
I've kept this answer language agnostic since a language wasn't given.
When the object is serialized, all the require information to rebuild it is encoded in way which can be retrieved. This typically includes the type of the object, as well as the value of all the instance variables.
When the object is deserialized, an area in memory of the correct size is allocated and is populated using the serialized information such that the new object is identical to the serialized one.
The running program can then refer to this new object in memory without having to actually call the constructor.
There are lots of little details which this doesn't explain, but this is the general idea of serialization/deserialization.
Are you talking about Java? If so, serialization is an extralingual object creation mechanism. It's a backdoor that uses native code to create the object without calling any constructors. Therefore, when designing a class for serializability, you need to make sure that a class created through deserialization maintains the same invariants (key fields being initialized) as you would through the constructor path. A third way to create objects in Java is through cloning, and similar issues apply.
Cloning and serialization don't interact well with the use of final fields if you need to set the value of that field to something different than what is returned by clone or the deserialization process.
Josh Bloch's "Effective Java" has some chapters that explain these issues in more depth.
(this answer may apply to other languages too, but I've only used serialization in Java)
Regarding .NET: this isn't a definitive or textbook answer, and I might be all-out wrong...
.NET Serialization needs to be seperated out into Binary vs. others (XML or an XML derivitave typically). Binary serialization is mostly a black-box to me, but it allows the object to be serialized and restored in their current state. XML serialization typically only serialized the public fields/properties of an object, unless overriden by adding a custom ISerializable implementation.
In the case of XML serialization I believe .NET uses Reflection to determine which fields and properties get converted to their equivalent Elements. Adding an [XMLSerializable] attribute will implement a default behavior which can be adjusted by applying other attributes at the field level (such as [XMLAttribute]).
The metadata (which Reflection depends on) stores all the object members as well as their attributes and addresses, which allows the serializer to determine how it should build the output.