I have 3 classes that map to my database. I need to insert an xml file into the database via these classes. The xml and classes are structured differently. Should I use xsd.exe to generate the classes of the xml and then map these generated classes to my database classes? Or should I use linq to xml to directly map the xml to the classes.
My experiences with XSD were that if it works for what you are using it for, its a very convenient thing, and completely worth doing.
On the other hand though, Depending on how familiar you are with using linq, you will probably end up with a better overall solution if you write the conversion directly.
XSD can be very convenient but I'm not always a fan of how the results are spat out. Overall Personally I'd lean towards using linq.
Related
I am currently developing an application that rely heavily on the .NET serializer for converting back and forth between objects and XML. It works fine, but embedding serialization/deserialization attributes directly into my model classes seam like a pretty poor design choice.
Is it somehow possible to sparate these attributes from the class itself? An example of what I would like to achieve can be seen here
Thanks in advance and have a great day
Unfortunately the answer to this isn't as easy and straightforward as you may hope. Serializers sometimes need hints on how to map a text representation of your data to the conceptual object representation (and vice versa). This is often more true of XML than JSON because it is more structured (elements, attributes, namespaces, schema, etc). The EF fluent model builder example you referred to isn't for serialization, it's for mapping to/from a relational schema, which is quite different from XML serialization.
Even tools like JSON.NET have these kinds of attributes, which are necessary when the names of your serialized members don't quite match the properties on your object, and you don't want to write a custom converter.
If the attribute pollution really bothers you, then you can introduce another layer between the models and the XML. You can then have types which contain the attributes and serve the sole purpose of serializing to and from XML, and then use a tool like AutoMapper or ValueInjecter to convert from that layer into your model layer.
I too don't always like attributes polluting my types, for example with MVC model validation attributes and especially for giving hints to EF on how my entity model maps to a relational schema. However this is one instance where I think it can be appropriate, because you get a lot out of it with a pretty minimal amount of code.
There seems to be at least one fluent XML serialization tool out there, but not sure how good it is:
https://fluentlyxml.codeplex.com/
http://trycatchfail.com/blog/post/fluent-xml-serializatione28093introduction.aspx
I want to build C# binary decoder. I have XML file which is describing data structure of binary file.
Next step is dynamically making data structures (in code) based on that XML.
Do you guys/girls have any comments, links, code, etc for me?
I am aware that this is general question, but I just want to start some where and I don't have clue from where.
EDIT:
Sorry need to remove code...
BR
Since you want to dynamically create the structures (rather than statically build classes based upon the XML definition), I guess you need a generic data structure which you can then query. What this looks like exactly would depend on what kind of data structures you're describing. Is it records and fields? Are there multiple record types in a hierarchy? If there's no hierarchy, you could just use a dictionary of key-value pairs for each field. If there is hierarchy, I'd have thought a navigable tree would cover most scenarios. You could use an XML DOM for this, but I think that's not the cleanest solution and I prefer to use generic tree structures. There isn't a built in one (see Tree data structure in C#), but it's fairly easy to create one with generics.
EDIT
The above assumes you want to dynamically create a structure to be used dynamically.
If you want to dymanically create a structure in code that will be used statically (e.g. you want to be able to write something like myDataStrucureThatWasDefinedInXml.MyProperty1), have a look at CodeDom.
And having thought some more about it, it really depends on what you want to do once you've deserialized your binary data. You might also want to look at the Expando object and Expression Trees.
To read and write content of XML document you can use XmlDocument class provided in C#.
Here are some links, which can help you:
http://www.codeproject.com/Articles/318876/Using-the-XmlReader-class-with-Csharp
http://www.codeproject.com/Articles/21167/XML-C-STARTING-GUIDE-First-Part
In my project I am using an XML-file for datastorage. I am accessing that file with linq-to-xml queries. Actually I have created that XML-file from my SQL-server database but as that tables in SQL contained more that 50 columns, the resulting XML-file is also having more than 50 elements...
Now while applying queries I initially load that XML-file in XDocument object and after that applying queries on that.
My main problem is that as it contain more than 50 element it is very difficult to write queries without intellisence support. Why it is not supporting intellisence? What have I done wrong? What can I do to get intellisence support?
LINQ to XML is based on strings and it isn't confined to documents that follow some schema. That's the reason you don't get IntelliSense, VS has no information about the schema.
If this is really important for you, maybe using something like xsd.exe to generate classes that represent the schema would be better for you.
It's not possible to get intellisense for Linq to Xml.
This is because you load a file at runtime and you expect it to have compile time intellisense. What if you would load a different file at runtime, would you then get a compile time error?
What you could do is generate classes from your Xml file and then deserialize your XML file into these classes. The you can use Linq To Objects to access the data.
Here is some documentation for creating your classes.
I have a little utility that runs through looking for certain things in XML files using LINQ. It processes a MASSIVE collection of them rather quickly and nicely. However, about 20% of a certain batch of files fail to be read and are skipped, failing because of the degree symbol's presence as ° in the files. This is the "Reference to undeclared entity 'deg'." a previous question was about.
The solutions offered in the previous question cannot be directly applied here. I am not at liberty to go around modifying the files, and making copies of them and replacing instances or inserting tags in the copies seems inefficient. What would be the best way to go about getting LINQ to ignore the undeclared entities, which have absolutely no bearing on what my program does anyway? Or is there perhaps a good way of getting an XDocument.Load to be fed some entity declarations beforehand?
Unfortunately entities form part of the well-formedness rules for XML (2.1 Well-Formed XML Documents). It seems like you're saying you want the XDocument.Load to load what is notionally an XML file, but does not in fact conform to the rules, which it won't do, quite reasonably.
If your users are passing you what are supposed to be XML files, but that have undefined entities, then either you have to get them to provide the files in a valid format, or manage the incorrectness youself at load-time, in the ways that have been suggested.
It seems to me, from your restrictions, that the neatest approach would be to follow the example linked-to and create some settings to pass into the XMLReader along the lines of (Validating an XML Document in the DOM).
If there are entities which aren't defined and aren't listed in public schemas, you'll need to create your own schema which defines all the entities you need. So, create a generic settings for the XMLReader which references your own, custom schema. Add the necessary entities to this schema as certain files fail to load and then you'll build up a list of all the entites that you need to define in order that the XML files are valid.
Then, for each document you try to load, create an XMLReader for the file using the settings above and call the XDocument(XMLReader) overload.
I am currently writing an application to manage some customers. The customers have some relations like orders. You can imagine this like the northwind database. I want to save the data in an xml file. My application should read, modify and save the data. I think, there are two approaches. The first approach is to save, read and modify the data with the XmlSerializer class. The second approach is to do the operations with LINQ-to-XML. All of my classes are written in simple C# classes. So, I am not sure. What do you think? What should I use for my needs?
Thanks in advance!
LINQ to XML is good for querying XML Documents.
If you're serializing/de-serializing an object, I would leave that to the XmlSerializer class.
Are you really, really sure that you want to use XML for this purpose? You can use SQL Server Compact Edition to have SQL Server capabilities that are built-in to your compiled application with no external footprint. A database is really a much better choice than using XML inthe way that you are describing.
There is much to consider when doing serialization. Even though the following is related to C++, it discusses some of the complications of serialization and what data structures to use when serializing.
http://www.parashift.com/c++-faq-lite/serialization.html
Also if another application is going to be using the output serialization, I would avoid using XmlSerializer class and construct my own schema with data migration and backwards-compatibility in mind.
Linq to XML so leater if you change your mind to set in EF or Linq to SQL will be easy.
I would recommend that you use the DataContractSerializer instead of the XmlSerializer. The XmlSerializer is still supported, however, only critical bugs are being fixed (see the comment to XSD.EXE - Incorrect Class Generated for Abstract Type With Derived Types on 10/1/2008:
Unfortunately, we're only proactively fixing the most critical customer impactful issues in XmlSerializer and xsd.exe. If this issue is causing business impact please contact Microsoft Product Support Services and we will be happy to explore various options.
The only downside, if it is one, is that the XmlSerializer allows you detailed control over the format of the XML. If you are only going to use the XML for your own purposes, then this doesn't matter, and the improved speed and feature set of the DataContractSerializer should be attractive to you.
BTW, it allows you "the best of both worlds". It can serialize data to a binary form of XML, which is more compact, but which is still XML, and can be read in by the XmlDictionaryReader class (which is an XmlReader).