I'm building some WPF application to manage my time. I'd like to save time spans for work time on project for a calendar day.
So my question is what's the best choice on how to save the data? I figured I could use an XML file, an Access database file or maybe a property. I´d like to save the data locally, so no SQL Server action in this case. :)
What do you think, which way to go?
I know you said no SQL Server, but I am reading that to mean you want no "server", and you want to store your data on the client. I also assume you probably wouldn't mind some manageability of your data. You know, things like backup. And transactions are always nice, so your data can remain consistent. So, while you could use XML (please banish all thoughts of Access from your mind), you would end up rolling your own persistence, when this is a solved problem.
So, please check out the free SQL Server Compact edition. It is lightweight, designed to run on a desktop or mobile device, and is easily deployable if your app ever needs to do that. And all the common persistence frameworks support it. And have I mentioned it is free (as in costs nothing)?
I'd suggest picking the easiest datasource possible and decoupling it appropriately so that you can drop in a new, different datasource at a later time when you figure out what's appropriate for your purposes. To that end, you may find something like XML or even plaintext to be the simplest thing that could possibly work.
Once you determine the characteristics that you'll need from your datasource, based on your actual usage, choose the appropriate backing store.
I don't think it's critical to make this decision up front because this is a personal project, not a commercial one.
I would grab SQLite either in its pure or a .NET-friendly form (doing a Google search for 'sqlite .net' will give you a few options there). It's super-portable and, in my opinion, easier to set up and distribute than SQL Server compact.
The important thing is to make sure you are not too tightly coupled to your persistence mechanism in your code, so in the future you could easily substitute any storage strategy you want.
One dead simple approach I've used in the past is your "xml file" idea. Simply create an object that describes the data you care about, and then serialize it to xml.
Greg is absolutely correct when he says make sure your datasource is decoupled properly so you can switch it out if your requirements change.