I am trying to do some contract first development, and have already designed a schema where an element has minoccurs=0 and nullable=false.
However I am not able to make a DataContract or XmlSerializer that generates this xsd.
I have an idea that this is not possible.
The only solution I have found is an ugly one, see it here.
In this solution i have to implement the IXmlSerializable and do the shema and the serialization myself. So I would have to maintin both the schema and the C# class -> Ugly
Has anyone found a solution to this or heard from Microsoft that this is not possible?
As far as I know, both XmlSerialiser and DataContractSerializer will generate object that will respect the schema if the object is filled correctly, but if the required values are not filled, the produced xml will not validate agains the schema.
You could try to use XsdObjectGenerator.
Related
I am new to ServiceStack, The extensiblity of this framework just blow my mind.
but it didnt seems to me any example to extend the data type of UserAuth. The IUserAuth interface seems to be tightly coupled with the framework.
Lets say i have a very large Database, and it is required to set UserAuth Id DataType as long instead of int. How can this be achieved?
You can’t change any of the existing IUserAuth schema properties but this answer covers different ways you can extend it
https://stackoverflow.com/a/11118747/85785
In my web method, I get an object of some third party C# entity class. The entity class is nothing but the DataContract. This entity class is quite complex and has properties of various types, some properties are collections too. Of course, those linked types are also DataContracts.
I want to serialize that DataContract entity into XML as part of business logic of my web service. I cannot use DataContractSerializer directly (on the object I receive in the web method) simply because the XML schema is altogether different. So the XML generated by DataContractSerializer will not get validated against the schema.
I am not able to conclude the approach I should follow for implementation. I could think of following implementation approaches:
LINQ to XML - This looks ok but I need to create XML tree (i.e. elements or XML representation of the class instance) manually for each type of object. Since there are many entity classes and they are linked to each other, I think this is too much of work to write XML elements manually. Besides, i'll have to keep modifying the XML Tree as and when the entity class introduces some new property. Not only this, the code where I generate XML tree would look little clumsy (at least in appearance) and would be harder to maintain/change by some other developer in future; he/she will have to look at it so closely to understand how that XML is generated.
XmlSerializer - I can write my own entity classes that represent the XML structure I want. Now, I need to copy details from incoming object to the object of my own classes. So this is additional work (for .NET too when code executes!). Then I can use XmlSerializer on my object to generate XML. In this case, I'll have to create entity classes and whenever third party entity gets modified, I'll have to just add new property in my class. (with XmlElement or XmlAttibute attributes). But people recommend DataContractSerializer over this one and so I don't want to finalize this unless all aspects are clear to me.
DataContractSerializer - Again here, I'll have to write my own entity class since I have no control over the third party DataContracts. And I need to copy details from incoming object to the object of my own classes. So this is additional work. However, since DataContractSerializer does not support Xml attributes, I'll have to implement IXmlSerializable and generate required Xml in WriteXml method. DataContractSerializer is faster than XmlSerializer, but again I'll have to handle the changes (in WriteXml) if third party entity changes.
Questions:
Which approach is best in this scenario considering performance too?
Can you suggest some better approach?
Is DataContractSerializer worth considering (because it has better performance over XmlSerilaizer) when incoming entity class is subject to change?
Should LINQ be really used for serialization? Or is it really good for things other than querying?
Can XmlSerializer be preferred over LINQ in such cases? If yes, why?
I agree with #Werner Strydom's answer.
I decided to use the XmlSerializer because code becomes maintainable and it offers performance I expect. Most important is that it gives me full control over the XML structure.
This is how I solved my problem:
I created entity classes (representing various types of Xml elements) as per my requirement and passed an instance of the root class (class representing root element) through XmlSerializer.
Small use of LINQ in case of 1:M relationship:
Wherever I wanted same element (say Employee) many times under specific node (say Department) , I declared the property of type List<T>. e.g. public List<Employee> Employees in the Department class. In such cases XmlSerializer obviously added an element called Employees (which is grouping of all Employee elements) under the Department node. In such cases, I used LINQ (after XmlSerializer serialized the .NET object) to manipulate the XElement (i.e. XML) generated by XmlSerializer. Using LINQ, I simply put all Employee nodes directly under Department node and removed the Employees node.
However, I got the expected performance by combination of xmlSerializer and LINQ.
Downside is that, all classes I created had to be public when they could very well be internal!
Why not DataContractSerializer and LINQ-to-XML?
DataContractSerializer does not allow to use Xml attributes (unless I implement IXmlSerializable). See the types supported by DataContractSerializer.
LINQ-to-XML (and IXmlSerializable too) makes code clumsy while creating complex XML structure and that code would definitely make other developers scratch their heads while maintaining/changing it.
Is there any other way?
Yes. As mentioned by #Werner Strydom, you can very well generate classes using XSD.exe or tool like Xsd2Code and work directly with them if you are happy with the resulting classes.
I'll pick XmlSerializer because its the most maintainable for a custom schema (assuming you have the XSD). When you are done developing the system, test its performance in its entirety and determine whether XML serialization is causing problems. If it is, you can then replace it with something that requires more work and test it again to see if there is any gains. But if XML serialization isn't an issue, then you have maintainable code.
The time it takes to parse a small snippet of XML data may be negligible compared to communicating with the database or external systems. On systems with large memory (16GB+) you may find the GC being a bottleneck in .NET 4 and earlier (.NET 4.5 tries to solve this), especially when you work with very large data sets and streams.
Use AutoMapper to map objects created by XSD.EXE to your entities. This will allow the database design to change without impacting the web service.
One thing that is great about LINQ to XML is XSD validation. However, that impacts performance.
Another option is to utilize LINQ and Reflection to create a generic class to serialize your object to XML. A good example of this can be found at http://primecoder.blogspot.com/2010/09/how-to-serialize-objects-to-xml-using.html . I am not sure what your XML needs to look like at the end of the day, but if it is pretty basic this could do the trick. You would not need to make changes as your entity classes add/remove/change properties, and you could use this across all of your objects (and other projects if stored in a utility DLL).
I know for a matter of fact that Type cannot be used when passing in to a WCF service. Does anyone have a complete list?
I'm not sure anyone bothered compiling a list, and i'm not sure there is any use in compiling one. Instead, there are requirements that a type must meet in order to be used in WCF contracts. Mainly, it has to be serializable.
I think it is the programmer's responsibility to verify that the types used in contracts are all serializable, and to make sure all custom types are serializing and deserializing properly.
Anything that you want to use in a WCF service needs to be serializable first, and secondly, it needs to be able to be expressed using XML schema. Also, WCF is interoprable by nature, so anything that's too specific to .NET (like exceptions, the .NET Type and so forth) should be avoided.
Anything non-serializable is out from the get go, and anything that cannot be expressed in XML schema can't be used either. This includes interfaces - you can only use concrete classes - and it also exludes generic types, since XML schema doesn't know how to handle generic types.
You're quite okay as long as you stick to the basic types (int, string, datetime etc.) and anything that is directly composed from those types.
Anything not marked Serializable, for starters.
We use custom type to represent Identifiers in our project. It has TypeConvertor attached and it always helped with serialization.
I've tried to use WCF Data Services to expose some data from our system, but faced a problem. Astoria framework do not recognize class as an entity even though I've decorated it with [DataServiceKey("Id")] attribute. If I change type of property to Guid - it totally works :(.
How could teach WCF Data Services to understand this simple class?
After a bit of research and a ton of Reflector work I've found that it's not possible.
WCF Data Services have monumental external metadata support described in detail by Alex James in very good series of posts.
However primitive data types creation is forbidden and key property of the entity should be of a primitive type. Moreover there is no pre- and post- execution hook available to provide run-time conversion from and to string type.
This and limited support of LINQ from NHibernate makes Astoria pretty unusable for me now. Witch is very sad.
As long as the class has a property Id DataServices should serialize it properly. You don't even need the attribute if the property is named ID. Did you see the example I did here. Also, you will find a complete list of OData related articles on http://www.Odataprimer.com. Maybe one of those will help.
Is there are an easy way to store some of entitie's properties in a column as a bulk, as XML or something? Querieng by those properties of course is not an option, but it still'd be valuble to be able to extend data model without database migration.
For NHibernate you can use dynamic-component
http://nhibernate.info/doc/nh/en/index.html#components-dynamic
or
using the dictionary as a name-value list
nhforge.org/doc/nh/en/index.html#collections-mapping
or even Duck-Typing
http://fabiomaulo.blogspot.com/2009/07/duck-typing-with-nhibernate.html
As far as I know you are not able to do this directly with NHibernate, but you could implement a private property which composes and decomposes your fields to a string and map to that property instead of mapping your fields directly.
But I am not sure if this really something you should do in the first place. Usually requirements tend to come up during development and lifetime of an application and once you are going to need one of the fields - even if you now think you will never need to query for that field - you will have a hard time. Adding a column to a table of an existing database is not much of a deal and you still need to update the xml for every tuple in the table, so I really think it is better to store only one field in a column.
Best Regards,
Oliver Hanappi
Not in NHibernate. I don't know about Entity framework.
You still need a database migration to store the XML field, so it won't prevent you having to do a database schema update when you find this feature in Entity framework or some other framework.
Yes, you can do this in NHibernate using a serializable object and an IUserType implementation. This link describes how to create an IUserType implementation for a SQL Server XML field and this link describes how to build on that to serialize an object to an XML field.
You could try converting the xml to a string before you store it in the database.
The Entity Framework does not support
a native-XML data type. This means
that when an entity is mapped to a
table with an XML column, the
equivalent entity property for the XML
column is a string. Objects can be
disconnected and serialized as XML.
For more information, see Serializing
Objects (Entity Framework).
http://msdn.microsoft.com/en-us/library/cc716791.aspx