So far all the serialization examples I have found on the web are related to storing arrays or list in a file. With each class of object having to be serialized into their own file such as a ".bin". The root of my problem is that I want to have the information for my product local stored, but I'm so use to working with sql. It's hard for me to visualize how to store information locally. If C# is anything like asp I should be able to connect to an Access database, but that pretty much defeats one of the ideas of serialization which is user non-readability. Is there a serialization method similar to using table and fields or at least allowing you to store all user information in one file?
You could use a ADO.NET DataSet that is serialized and stored locally. It will contain all of the data structures that you're familiar with and allow you to query the data the way you seem to want to and if you serialize it with a Binary Serializer, it will be unreadable to end-users.
Also, you could look at SQLite as an alternative to using DataSets.
SQLite is a software library that
implements a self-contained,
serverless, zero-configuration,
transactional SQL database engine.
SQLite is the most widely deployed SQL
database engine in the world. The
source code for SQLite is in the
public domain.
NHibernate with SQLite is a great combination as well.
Cheers.
Check out NHibernate. That will give you your 'database-like' storage.
If it's human-readability you're after, consider serializing your objects using XML. .Net has decent support for serializing (and deserializing) objects using both XML and binary formats.
The tutorial I used for learning serialization in C# is this CodeProject article.
Update:
I misread one point you made: serialization does not necessarily mean human-readable or not - if you decide to serialize, figure out if you want the data readable or not. Binary serialization is likely to be more compact and less readable.
Related
In my situation, I have a C# DLL I wrote myself that has been registered in a SQL Server database containing sales/customer data. As of now, I'm a bit stuck.
The DLL makes a call to a remote server to obtain a token. The token is then added to the database. Ideally, the next step is to retrieve data from the SQL server into the DLL and then build and post a JSON file to a remote server, using the token the DLL retreived.
Where I am stuck is there are 134 elements, with different data types, in the receipt section of my JSON file alone. I will need to be able to handle all of that data in my C# DLL and in the future I may need to pull a lot more data into this JSON file to be posted. I've done some reasearch and using user defined type (UDT) wouldn't quite work and from what I can tell, is an option I should stay away from. My other two options I know of would be to either export to XML and parse it in my DLL or to create and read in 134+ variables.
My question is: Is there a simpler way to do this besides XML/hard coding? It would be ideal if there was a way to use an array or an object but neither seem to be supported according to what I've read here
Thank you.
Important note: Because of the database and the JSON library I'm using, I'm working in .Net framework 2.0
I would recommend you to use XML serialization on the C# side. You create an object that models your database schema.
As you are using .NET 2.0 you have already a good set of base classes to model your database schema in an object oriented way. Even nullable columns can be mapped to nullable objects to save memory and network space.
From your SQL side you use the FOR XML clause, that will change the output of your query from tabular to XML. You have to make just one good SP that will create XML in the exact hierarchy as your C# objects.
This XML has to match the names and the casing of the classes and the properties of your c# class(es).
Then you will de-serialize this XML from the C# side in no more than 10 lines of code. No matter how big or how complex the data hierarchy is, and you will have instantly in memory objects that you can immediately serialize into JSON again.
Let me know if you need some good examples on how to achieve this. And please clarify if you are running inside of the SQL Server CLR execution context, as you might need special permissions for serializing/deserialize data.
I guess its a very primitive way of achieving what Entity Framework does. but it works.
You should probably stick with using XML as your data is semi-structured. Especially if you know your schema will be changing overtime. SQL Server is not yet an OODBMS.
Developing a small WPF Windows Client application in C#, Visual Studio.
It needs a whole lot of constant tabular data, and I'm interested whether it's best to put it in a local database, or load it from a text file, or some other solution?
Note that the data itself is complete and sealed, not needing ever to be edited after compiling.
You can always put it in a resource.
you already have the answer where to store you data. as for file format... my vote goes to XML
SQLite is often used to store data of this nature especially if the data fits well into the paradigm of relational databases or if you have complex requirements for extraction in which SQL queries work best. There is a native .NET data provider for SQLite here.
I have a variety of rich data structures (primarily trees) that I would like to persist to disk, meaning I not only want to write them to disk but I want a guarantee that the data has been fully written and will survive a power-down.
Others seem to design ways to encode rich data structures in flat database tables as lookup tables from parent to child nodes. This facilitates running SQL queries against the data but I have no need for that: I just want to save and load my trees.
The obvious solution is to store everything as a blob in the data base: a single entry perhaps containing a long string. Is that an abuse of the database or a recommended practice? Another solution might be to use an XML database? Are there any alternatives to databases that I should be considering?
Finally, I'm doing this from F# so a turnkey solution for persisting data from .NET would be ideal...
EDIT: Please note that formatting (e.g. serialization) is irrelevant as I can trivially convert between formats with F#. This is about getting an acknowledgement that a write has been completed all the way down to the non-volatile store (i.e. the disk platter) and no part of the written data is still being held in volatile store (e.g. an RAM cache) so that I can continue safe in that knowledge (e.g. by deleting the old version of the data from disk).
Some of the constructors for .NET's FileStream class take a parameter of type FileOptions. One of the values for FileOptions is WriteThrough, which "Indicates that the system should write through any intermediate cache and go directly to disk."
This should ensure that by the time your write operation (to a new file) returns, the data is committed to disk and you can safely delete the old file.
This can be done via Serialization.
The .NET Framework includes many built-in options for serializing your data to disk, including using binary or XML-based formats. Detailed How-To articles are provided in the MSDN Documentation.
In order to do this, you will require a resource which will allow you to engage in a Transaction (more often than not, you would use a TransactionScope.
Most databases will participate in a Transaction if one is contained. Disk operations can also be managed by a Transaction, but you would have to do some specific work in order to utilize it in .NET.
Also, note that this is only available on Windows Vista and later.
If you go the database route, then you could store the serialized contents of your trees in a blob (or text, depending on the serialization mechanism).
Note, you can also use the FILESTREAM functionality in SQL Server (2008 and up, I believe) to store your files on the filesystem and gain the benefits of transactions in SQL Server.
I haven't used db4o from F# before, but it's all about persisting CLR object graphs to disk in a transactional manner. If it works with records and discriminated unions, it might suit you.
Edit: I just tested db4o 8.0 (.NET 4 version) and it seems to handle both record types and discriminated union hierarchies perfectly well.
Try using XMLSerializer (System.Xml.Serialization).
http://msdn.microsoft.com/en-us/library/system.xml.serialization.xmlserializer.aspx
It can automatically persist complex data structures based on their properties, and you can use attributes to control the output, if you wish:
http://msdn.microsoft.com/en-us/library/83y7df3e.aspx
Slightly OT as the OP didn't want XML, but seeing others mentioned the XML formatter...
If you want textual persistence, the SoapFormatter handles cases
(cycles/object-graphs) that the default XML formatter does not - its XML is not as readable as XMLFormatter's, but it's more readable than binary :)
I'm faced with the challenge of writing an object persistence mechanism that serializes/deserializes to a SQL database and XML files.
For the sake of illustration, imagine I have a graph of objects that has a single root object. Maybe a "tree", for example, which has all manner of child objects -- leaves, brances, nuts, squirrels, birds and the like.
I need a suggestion for an architecture that seamlessly moves between loading & saving a "tree" from a file and/or database. It needs to be able to load a "tree" from a file and save it to a database, or the other way around.
I'm currently using Entity Framework for my SQL persistence, and I'm happy enough with it. For the XML I'm using XDocument, which I also like a lot, but I'm wondering if there isn't some framework out there that already does all this.
Unless you want to do querying on your objects in Sql Server (or there are other sources that may update/manage relational data), using EF to convert into relation schema is a bit overkill. If all you want is to persist your object graph in different mediums then you should consider runtime serialization or DataContractSerializer. Essentially, you will get binary data or XML that you can dump into any storage medium including Sql Server. This will free you from changing relation schema in sql server when your object structures changes. However, you must consider versioning your objects while going from serialization approach.
You can try using the older, yet very nice XmlSerializer.
ps. need to watch out for anything Entity Framework may require from you when loading an object you serialized to a xml file.
Are there any strict requirements around the entities being saved in XML format? If not, another option could be to use SQLite (http://sqlite.phxsoftware.com/) with the entity framework when you need local/filesystem persistence.
I've recently taken up learning some C# and wrote a Yahtzee clone. My next step (now that the game logic is in place and functioning correctly) is to integrate some method of keeping stats across all the games played.
My question is this, how should I go about storing this information? My first thought would be to use a database and I have a feeling that's the answer I'll get... if that's the case, can you point me to a good resource for creating and accessing a database from a C# application?
Storing in an XML file actually makes more sense to me, but I thought if I suggested that I'd get torn apart ;). I'm used to building web applications and for those, text files are generally frowned upon.
So, going with an XML file, what classes should I be looking at that would allow for easy manipulation?
Here is one idea: use Xml Serialization. Design your GameStats data structure and optionally use Xml attributes to influence the schema as you like. I like to use this method for small data sets because its quick and easy and all I need to do is design and manipulate the data structure.
using (FileStream fs = new FileStream(....))
{
// Read in stats
XmlSerializer xs = new XmlSerializer(typeof(GameStats));
GameStats stats = (GameStats)xs.Deserialize(fs);
// Manipulate stats here ...
// Write out game stats
XmlSerializer xs = new XmlSerializer(typeof(GameStats));
xs.Serialize(fs, stats);
fs.Close();
}
A database would probably be overkill for something like this - start with storing your information in an XML doc (or series of XML docs, if there's a lot of data). You get all that nifty XCopy deployment stuff, you can still use LINQ, and it would be a smooth transition to a database if you decided later you really needed performant relational query logic.
A database may be overkill - have you thought about just storing the scores in a file?
If you decide to go with a database, you might consider SQLite, which you can distribute just like a file. There's an open source .NET provider - System.Data.SQLite - that includes everything you need to get started.
Accessing and reading from a database in .NET is quite easy - take a look at this question for sample code.
SQL Express from MS is a great free, lightweight version of their SQL Server database. You could try that if you go the DB route.
Alternatively, you could simply create datasets within the application and serialize them to xml, or you could use something like the newly minted Entity Framework that shipped with .NET 3.5 SP1
I don't know if a database is necessarily what you want. That may be overkill for storing stats for a simple game like that. Databases are good; but you should not automatically use one in every situation (I'm assuming that this is a client application, not an online game).
Personally, for a game that exists only on the user's computer, I would just store the stats in a file (XML or binary - choice depends on whether you want it to be human-readable or not).
I'd recommend saving your data in simple POCOs and either serializing them to xml or a binary file, like Brian did above.
If you're hot for a database, I'd suggest Sql Server Compact Edition, or VistaDB. Both are hosted inproc within your application.
I would recommend just using a database. I would recommend using LINQ or an ORM tool to interact with the database. For learning LINQ, I would take a look at Scott Guthrie's posts. I think there are 9 of them all together. I linked part 1 below. If you want to go with an ORM tool, say nhibernate, then I would recommend checking out the Summer of nHibernate screencasts. They are a really good learning resource for nhibernate.
I disagree with using XML. With reporting stats on a lot of data, you can't beat using a relational database. Yeah, XML is lightweight, but there are a lot of choices for light weight relational databases also, besides going with a full blown service based implementation. (i.e. SQL Server Compact, SQLite, etc...)
Scott Guthrie on LINQ
Summer of nHibernate
You can either use the System::Xml namespace or the System::Data namespace. The first gives you raw XML, the latter gives you a handy wrapper to the XML.
For this situation, the [Serializable] attribute on a nicely modelled Stats class and XmlSerializer are the way to go, IMO.