Data file format for .net thick client app_问答_开发者

I've read a variety of recommendations on this, and just am curious what the "state of the art" would be for this-

I've built a traditional thick client (wpf, actually) application which is using datasets (strongly typed) as the data layer- used in-memory during the lifespan of the app, and binary serialized (and compressed) to store to a file. The file doenst need to have any compatability with other apps etc, so I have the freedom to choose whatever storage mechanism I choose. The app does also communicate with webservices, which it is currently using this same strongly typed dataset for.

The app includes all kinds of data in this file, from included images, to rather long lists of numeric values (potentially over 100k doubles), to basic text etc.

So, if I wanted to modernize this app, I'd probably prefer to use various generic lists of objects for the data layer in-memory, which could then still be binary serialized out to a file. But are there better ways? I know using a database for the file would allow me to update specific items only, instead of re-serializing the whole thing, but right now I'm not having to deal 开发者_开发问答with the headache of figuring out which items have changed and need updating etc. And if I do stick with just serializing everything, are there better or more standardized/open ways to do this - something like protocol buffers or bson comes to mind.

I'll observe some answers and add any clarification here if needed. TIA.

The question is tagged 'sqlite'. It's as though you've made up your mind, maybe, already? :-)

I always try to plan for the future, and would therefore recommend SQLite to you even though you are willing to serialize the entire file now and don't need to know which particular piece of data has changed. But someday you might.

SQLite is robust, small-footprint, with a non-invasive installation, and the System.Data.SQLite data provider is good, and has support for UDFs written in a .NET language. It would give your app not only a more granularly addressable data-store, but another set of capabilities and intelligences, and would therefore be superior to a 'passive' data-store.

I haven't used SQLite to store images, so I can't comment on that requirement.

The real question should be why are you considering changing your methodology if it works? If your dataset may grow to something larger than will fit in memory comfortably, then you would be pushed towards some form of database system (there are many that would work). If it is fairly statically sized, no requirement for interoperability with other third party applications, and works for you, you needn't change it at all.

If your data is "simple": I.e. tabular or hierarchical (DAG) without complex references between objects, then you have quite a lot of choices. In this case the discussion becomes more "what kind of database", i.e. relational or document based. The choice depends on the structure of the data, volume of data etc. I'd evaluate Sqlite, sql server compact, googles protocol buffers, and perhaps some nosql implementation such as ravendb.

If your data is a general object graph (not a an acyclic graph) then you are not so lucky. Anything but direct serialization of the entire graph is difficult to implement when you need to preserve object identities. Even more difficulty arises by e.g. references to singletons (which the BinaryFormatter actually handles quite well). The general solution is just writing to file with BinaryFormatter, but you will run in to 3 new problems: performance, file size and file format compatibility.

If you decide to go for binary serialization (which should only be the case if your object graph demands it), you can implement custom serialization with ISerializable or the newer serialization attributes to control serialization in detail and provide a more robust format. The automatic format from the BinaryFormatter for example does not deal with auto properties well.

If you want a more flexible format that allows for metadata etc, I'd suggest using the System.IO.Packaging classes to create an OPC archive file with your data inside a PackagePart.