Lightweight Local Data Store

marbol posted on Monday, September 18, 2006

I'd like to set this up using a lightweight local data store, and not a database. Locally, I'd like to just use a plain simple XML data file to hold everything. The file could just be an XML file with a single root and all remaining objects stored in it.

Does anyone know of any code that does this already? Or is this mine to write? :)

Thanks

 

DeHaynes replied on Monday, September 18, 2006

Your looking for an in-memory database system that stores the data as XML files when not online?

 

You can accomplish this yourself with Datasets and the built in XML code inside Visual Studio.  Something like:

DataSet ds = new DataSet();
ds.ReadXml(file,XmlReadMode.Auto);

...

ds.WriteXml("C:\test.xml");

RockfordLhotka replied on Monday, September 18, 2006

I know you said no database, but still you might consider SQL Everywhere, which is a 1.4 meg set of DLLs that provides a very lightweight relational model. Or db40, which is also very small and provides a lightweight object database model.

As was pointed out, the DataSet itself is a perfectly good approach, giving you lots of power with very little effort.

Finally, you could use a data transfer object (DTO) approach, along with the XmlSerializer and  System.IO namepace (or My.Computer.FileSystem in VB) to very easily read/write an object graph to a file. The data will be in XML on disk, but in object form in memory - very simple and nice.

marbol replied on Monday, September 18, 2006

Yes. I have to have no databases. I'll look into the dastaset, but currently I already use the XmlSerializer. Of course, this requires the classes to have public empty constructors so the XmlSerializer can construct them. I guess there is no way around that.

RockfordLhotka replied on Monday, September 18, 2006

I wouldn't recommend trying to save/restore your actual CSLA business objects using the XmlSerializer... That serializer is far too limited in what it can do, and eventually you'll use a readonly property, or a more complex collection type, and you'll be unable to serialize your objects.

You will be far better off if you copy the data into/out of your business objects from some sort of data object - like a DTO or dataset.