What would be a good approch for using XML as data persistence for a small C# app? [closed]

Question

I need some opinions on what would be a good approch for using XML as data persistence for a small C# app. This is a stand alone app, users do not share the same data persistence, hence, file access is exclusive. This is why I thought of XML in the first place.

I know my design patterns, so if I write the usual layers, I can isolate the persistence and then change it afterwards, if needed. Then again, it's a small app, so I need to write it fast.

Should I just use Linq to XML and get over with it? If so, what would be my rewriting efforts if I decide to replace XML with a embedded database? How's Linq performance in writing into the XML file?

But if I don't go with Linq, what would you guys suggest?

Update

By the comments I got, I might need to specify a little more. This is a report card app for teacher use. These are my main entities:

• Student
• Course
• Teacher (there should be only one, but I'll store it because of future integration possibilities)
• Grade (a student can have more than one grade in each course)

Now some questions:

• Under the hood, should I have one XML file per entity?
• Under the hood, should I use Linq to XML? Is there something else to even be considered?

And some comments

• I understand that I should interface with the "persistence class instance" using IEnumerable<MyEntity>, on either inputs and outputs. That gives me flexibility.
• Although I'm really open to suggestions, I really do not want to consider embedding a database right now. This small app is an exciting opportunity to get to work and experiment with new things on production (not only testing) and little risk.

Answer 1

I suggest you:

• Define a model (one class) representing the data that needs to be stored (can be hierarchial)
• Use serialization to serialize or deserialize to XML or binary or even JSON if needed.

Answer 2

It might be much easier to use SQL Server Compact That way it is easier to use the Entity Framework tooling and to optionally migrate to a fully fledged SQL Server later on.

Answer 3

XML/JSON works best if you write the entire document at once, trying to append data may also be ok, but at some point you will probably want to insert/update partial data in the middle of the document/file, and that is when it gets hairy.

If you can live with a solution that reads the data into memory (at once or partially by querying) and then at some later point writes it all back to the file, then it works well with a single XML/JSON file. As long as you do not need to periodically update/insert/delete partial data from the file, a file should do it (although performance could be an issue).

One way that I have used many times is to define a XSD Schema, including constraints, data types etc. to your liking, then set up a pre-build step that automatically generates a serializable C# class hierarchy for you (using for example XSD.exe). Using normal XML serializing funcationality it is then very easy to load (and optionally validate the XML via your XSD document) the entire document into memory, read/manipulate it (query/update/insert/delete) and later serialize the entire object hierarchy back into XML.

See this page for info on XSD.exe.

This approach quickly gives you a pretty useful and solid foundation to build upon. It should be sufficient for a while, but you may have to re-write quite a bit of it if you are later moving on to a database-based solution, if you do not abstract away the data access internally from the beginning.

If an pure file-based solution is not sufficient, go for some kind of database-oriented solution, preferably some kind of embedded database, for example SqlLite or BerkeleyDb.