Is there a naming convention for a class which manages serialization and de-serialization of data? An example of such class would be the MFC CDocument class which acts as the bridge between File data and App data. As in, what are these types of classes typically called?
At least in the BCL (.NET Base Class Library), these are called Serializers or Formatters.
Examples include the XmlSerializer, BinaryFormatter, DataContractSerializer and JavaScriptSerializer.
All of these classes manage both serialization and de-serialization.
Related
I have a couple of questions related to inheritance in Windows Runtime Components authored using C++/WinRT. Firstly why is there a restriction that classes, if they have a base class, must have ultimately derive from a class in the Windows.* namespace?
Secondly, what is the best way to work around this. In fact I don't really want consumers to be able to derive from my class, but I'd like to derive from a base class in the implementation in order not to rewrite code. At the moment my implementation class is a lightweight wrapper around a standard C++ class that uses standard C++ inheritance. But is there a way to simplify this? Can a list one implementation class as the base class of another? I am mainly familiar with C# where multiple inheritance is not possible, so am not sure about this sort of thing.
Any runtime class (that you declare in your application) that derives from a base class is known as a composable class. The ultimate base class of a composable class must be a type originating in a Windows.* namespace;.
And if you want to inherit custom runtimeclass, the Windows App Certification Kit tests will produce errors. From this thread, it seems that you can only declare a C++ native class and implement the interfaces. Let the implementation classes inherit from it.
What is the benefit of keeping attribute in WCF service?
What I mean is why to give them [Datamember] and [Datacontract] and what's advantage and disadvantage?
What happens if I make attributes and its class in different project with simple class library project and I insert its "dll" reference to WCF service class library, which contains all operation that are [ServiceContract] and [operatinconntract] on this attribute.
WCF parameters need to be serializable. Value types such as int and string will be by default and therefore just work.
DataContractAttribute is used to mark complex types as serializable. See Using Data Contracts for more information.
Pre-WCF, serialization was done using the XmlSerializer class and by marking a type as [Serializable] it meant that all members were serialized by default.
However with DataContractSerializer which is the preferred serializer used in WCF, members of a class will not be serialized unless indicated.
Re having contract types in a different assembly - yes this is possible, and actually it's best practice to keep your contract types separate from your service implementation assembly.
Are there any ways to tell WCF to serialize the whole class when it returns? Do I literally have to add DataMember to every property?
Since .NET 3.5 SP1, you don't have to do this anymore.
If you don't have any [DataContract] and [DataMember] attributes, the DataContractSerializer class will behave like the old XmlSerializer: it will serialize all public read/write properties that are listed in the class.
You do lose a few things in the process though:
since you don't have [DataMember] attributes, you cannot define an order of the fields anymore - they'll be serialized in the order of appearance
you cannot omit a public property (since that would require [DataMember] on all other properties/fields)
you cannot define a property to be Required (that would be on the [DataMember] attribute again)
your class now needs to have a public, parameter-less constructor (usually not needed for data contracts)
Read all about it in detail from Aaron Skonnard at Pluralsight.
I love marc's answer, but I want to add some more info.
DataContractSerializer and DataContractJsonSerializer both support, out of the box, many other serialization models as well. This includes IXmlSerializable, Serializable, and ISerializable. POCO support was added in .NET 3.5 SP1, but support for these other models has always been there since .NET 3
This blog post details the extent of the support and more importantly, the prioritization of different models by the serializer (i.e., it tells you what DataContract-based serializers would do if you have one type decorated with multiple serialization models)
So, if you read that blog post, you'll notice that POCO support is last in the priority list. It is the serializer's last resort, if there is absolutely no other serialization programming model available on the type or its parent. For example, if the type is an enumerable of some sort, it will get serializaed according to traditional collection rules. If it's ISerializable or Serializable, it will get serialized according to their serialization rules.
Another important difference: during deserialization of all other types, the default zero-params constructor is never called. For POCO types, it is always called! This gives you an additional hook you don't have so easily in other serialization models!
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
I know there have been similar questions on this topic but I wasn't completely sure they were solving the same problem. So just to be clear...
I have an existing class library that has namespaces for types, business logic and data access. The classes in the logic and data access namespaces are static and have basic crud methods to fill the type instances with data or take type instances that are already full and do inserts or updates in the database.
Now, in addition to the existing applications that reference this library directly, I want to also create a WCF service so that other applications can consume the objects and methods that way.
Every WCF turorial that I see creates the domain objects in the service project - but I don't want my objects defined in two places.
So I was thinking I could reference serialization in my existing class library and mark the type classes as [DataContract] and the properties as [DataMember]. Then, in the WCF project, create the [ServiceContract] interfaces with [OperationContract] methods to match the static logic classes and methods from the existing library that I want to expose. Then, from the WCF project, reference the existing class library and implement the WCF interfaces by having methods in it that call the existing library logic methods which return the existing library types.
Is this a good pattern?
It sounds good but retrofitting serialization tends to be more trouble than it seems at first. I would suggest that you build some lightweight data contracts into a service layer and then build a small tier that sits between your service layer and the business layer to translate the data contracts into business objects and vice-versa.
Assuming your business object can be serialized (have attribute Serializable) one approach could be creating DataContainer object, which will be your data contract. This object would be used in your CRUD methods.
For example your interface could be
Update(DataContainer obj)
Insert(DataContainer obj)
etc.
Then you would use Binary serialization to pack your object into array of bytes and pass it this way through WCF. On the other side you would deserialize them using again BinarySerialization. You just have to make sure that both sides (client and server) have valid version of assembly with your business objects types.