Serialization vs LINQ - c#

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).

Related

How to deal with a XML based protocol where the response may conform to one of two XSDs?

I have to read and write data through a protocol where the response XML maybe different according to the error state of the server application. If the response is good it uses let's say Xml_1 with a specific schema but if the response indicates an error it uses Xml_2 with a complete different schema. The good design , in my opinion would be to incorporate the error state to the first schema, but we are just consumers of the this service and we don't have access to the design of the server application. My solution is to (using C#) read the XML response as string, do some searching in order to understand which XML schema is in use and then using the appropriate XML Serializer to convert the response to an object. Is there a more elegant solution?
Is the union of the two schemas a valid schema? (This will typically be the case, for example, if they use different namespaces, but it's likely not to be the case if they are both no-namespace schemas or if they are two versions of the same schema).
If the union is a valid schema, then you could consider validing against that.
Otherwise peeking at the start of the file will often be enough to tell you which vocabulary is in use.
It's possible to parse an XML document without validation, inspect it, and then validate the already parsed document. It's even possible to do this in a single pipeline without putting the whole document in memory. But the details depend on the toolkit you are using. You've tagged the question C# - I'm not sure if this is possible using the Microsoft tools, but it should be possible I think using Saxon-CS. [Disclaimer, my product].

long to xml, xsd.exe, custom classes

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.

Best way to store small amount of data

I'm new to windows app and I would like to know what the best way to save a small amount of data, like 1 value a day.
I'm going for the text file because it's easy, but I know i could use MS Access.
Do you have other option ? Faster or better ?
Since you are already considering using a MS Access database, I would recommend using SQLite. Here's a quote from their site (SQLite Home Page):
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.
It is really very easy to use - no installations required, you simply need to reference a DLL.
If you need to read it then use a plain text file.
If you need to read the values back into the application then serialize to an XML or binary file by making your user data serializable possibly by having a List of values in your object.
How do you want to use the data? Do you just want to look at it once in awhile? Do you plan to analyze it in a spreadsheet? Etc. Based upon what you say so far, I would just use a text file, one value per line. Even if later you wanted to do more with it, it's easy to import into spreadsheets, etc. If the daily data is a little more complicated (maybe a couple of different values for things each day), you might consider something like YAML.
Why stray from the path? XML gives you the ability to expand on it later without having to rethink everything.
Its mainly dependent upon the complexity of the data that you want to store. If its just DateTime some other simple built in type you would be able to recreate that object as a strongly typed one easily. But in case if its more complicated I would suggest you to create a serializable class (link on how to create such class is here) and then use one of Binary or SOAP serializations based on the size, security and other such needs. I am suggesting this as it would be best to be able to recreate objects as strongly typed ones from a flat file rather than just trying to parse what's there in the flat file.
Please let me know in case you need more clarity.
Thanks,
Sai Pavan

Handle xml data in an activerecord pattern way: Any way?

I would like to handle xml data in an activerecord way, so 1 class for each xml structure (I will need an xsd obviusly) and the possibility to do operations like Users.FindAll() like castle activerecord do.
The problem is, obviusly, that those are xml file, not relational databases.
Are there any library to achieve this? If is MS library and not a third party library is better, obviusly.
To understand why I would like to achieve this, I'll explain the program I'm building so you can eventually give me some suggestions if a different approach is better:
The program "output" will be something like a long MS-Word (or pdf) document which will contains information about how a company handles the privacy of their customers, following the local legislation.
I will have, so, a "global" xml file which contains something like Jobs (as defined in law, but law can change so should be editable by the user) that each employee can have in it's company (there will be other data too, this is a generic example).
Then, I will have an xml file for each company the user would like to use this program for. This xml file will have a list of employees where each emplyee have a reference to the Job (chosen from the global xml file).
Obviusly the program will have much more data, but this explains how it works.
I'm still not sure if I must use a relational databse, what really frighten me in case I use one, is that I will have "troubles" in allowing the user to export/import data if he install the program on a new computer. Also I would like to avoid to force the user to install a database on his computer (well, an sqlite-like database could be ok because is on a file).
Any suggestion about this?
Thanks to everyone
Although Linq-to-XML is pretty easy to use, there are many more things to do when it comes to reading and storing related data in a way a RDBMS does. An RDBMS is all about referential integrity, ACID transactions, concurrent users, performance enhancements, to name a few elements that spring to my mind now. Thinking of this daunting task, I think doing this all by yourself is more scary than deploying a database file.
There are some XML-based databases, but I don't know how mature and user friendly they are. I even remember having read of database systems based on plain text files.
I would go for the paved roads and use a relational database, possibly a local database, as you already suggested. Lots of support and tooling available.
How about to use Linq to Xml?

Approach to process huge xml files in C#

Can someone please guide me with this problem?
In my institution, we process xml files of huge size(max 1 GB) and insert the details into a database table. Per current design, we are parsing xml file with XmlReader and form a xml string with required data, which will then be passed into a stored procedure (xml data type) to insert the details into db.
Now the problem is we are not sure if there would be a better approach other than this ? so please suggest if are any new features available with .Net 3.5 and/or sql server 2005 to handle this in a way better than our approach.
Any help in this reagrd would be highly appreciated.
Thanks.
Do you care at all what is in the XML-file? If not, you can just use a StreamReader and get the text from the XML and just pass it along to the database.
If you need to validate that the XML is correct, it is a good idea to use XmlReader.
However, just dumping 1GB of XML into your database seems a bit weird, what is the purpose of this XML data? Is it a lot of nested elements? Maybe you could de-serialize it and store each object in the appropriet table instead, which would imo lead to a easier understandable design.
There are a couple of things you can think of to make the design of your software easier/better:
Does more than one XML file occure in the database at once?
How is the data shared between applications?
Have you considered using MemoryMappedFile?
Is it possible to de-serialize the XML into entities instead and store them approprietly?
I suspect that if there are any performance issues it will be with the stored procedure and the database side of things rather that reading the file.
Why are you storing the XML file in a database table? I would suggest using a different solution would be appropriate, but without knowing more details about exactly what it is you are trying to do it is hard to advise.
If each first-level element in the xml is a record, i.e.
<rootNode>
<row>...</row>
<row>...</row>
<row>...</row>
</rootNode>
Then you could create an IDataReader implemention that reads the xml (via XmlReader) and presents each as a record, to be imported using SqlBulkCopy. Pretty much like my old answer here.
Advantages:
SqlBulkCopy is the fastest way to get data into a database
stripping it into records makes appropriate use of a database, allowing indexing and proper typing
it doesn't rely on a huge BLOB going over the wire in an atomic way (necessary for the xml data type)

Categories

Resources