Ok, so I am working on a c# windows forms application and it uses different types of structures that hold data and display to the user. I want to use a saveDialogBox to allow the user to save the information(i.e configuration, state). The only way I can think to do this is to make a routine that goes through the structures and write the corresponding elements to a text file. Upon loading this routine would be used to load the data back.
This is of course a dumb way to do it I'll admit. Anything I've done in school was only writing to text files. Is there other ways to make some formatted file to save and load from?
I've been looking at serialization to save objects to files. I am not too sure how all this works though. help.
to save your application setting .. I think these links will help you
http://msdn.microsoft.com/en-us/library/aa730869%28VS.80%29.aspx
http://www.thescarms.com/dotnet/AppSettings.aspx
and
How to use settings in Visual C#
My 'Old School' way of doing this has always been to save settings during the program execution to a database (providing that you take the time to ensure you're not hammering the database with updates / inserts).
If my application needs to be more efficient AND I need to easily be able to recall the saved settings I serialize to XML using System.Xml.Serialization (from memory). XML serialization is human readable which is helpful (but not the most efficient in terms of processing time).
If I need even more efficiency you can go the whole way and serialize to binary.
I'd suggest reading / understanding http://msdn.microsoft.com/en-us/library/Vstudio/ms233843.aspx in it's entirety before coming back here. I'd say once you read this you'll be far better equipped to make a decision on which way you want to take your application.
In my experience there aren't that many DUMB ways to solve problems however there is almost always a better way to solve them given enough time and research.
Related
I'm developing a PC app in Visual Studio where I'm showing the status of hundreds of sensors that are connected via WiFi. The thing is that I need to hold on to the sensor data even after I close the app, so I'm considering some form of permanent storage. These are the options I've considered:
1) My Sensor object is relatively compact with only a few properties. I could serialize all the objects before closing the app and load them every time the app starts anew.
2) I could throw all the properties (which are mostly strings and doubles) into a simple text file and create a custom protocol for storage and retrieval.
3) I could integrate a database with my app. Someone told me this is the best way to go about it, but I'm a bit hesitant seeing as I'm not familiar with DBs.
Which method would yield the best results in terms of resource usage and speed? Or is there some other, better way to go about this?
First thing you need is to understand is your problem. For example, when the program is running do you need to have everything in memory at the same time or do you work with your sensors one at a time?
What is a "large amount of data"? For example, to me that will never be less than million (or billion in some cases).
Once you know that you shouldn't be scared of using something just because you are not familiar to it. Otherwise you are not looking for the best solution for your problem, you are just hacking around it in a way that you feel comfortable.
This being said, you have several ways of doing this. Like you said you can serialize data, using json to store and a few other alternatives but if we are talking about a "large amount of data that we want to persist" I would always call for the use of Databases (the name says a lot). If you don't need to have everything in memory at the same time then I believe that this is you best option.
I personally don't like them (again, personal choice) but one way of not learning SQL (a lot) while you still use your objects is to use an ORM like NHibernate (you will also need to learn how to use it so you don't get things a slower).
If you need to have everything loaded at the same time (most often that is not the case so be sure of this) you need to know what you want to keep and serialize it. If you want that data to be readable by another tool or organize in a given way consider a data format like XML or JSON.
Also, you can use mmap-file.
File is permanent, and keep data between program run.
So, you just keep your data structs in the mmap-ed area, and no more.
MSDN manual here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366556%28v=vs.85%29.aspx
Since you need to load all the data once at the start of the program, the database case seems doubtful. The DB necessary when you need to load a bit of data many times.
So first two cases seem more preferred. I would advice to hide a specific solution behind an interface, then you'll can change it later.
Standard .NET serialization of sensors' array is more simple probably, and it will be easier to expand.
I understand how serialization works and was wondering if there is a way to store an object on the disk and work with the object and save the changes.
I am trying to avoid directly doing this:
Opening the file
Deserializing the object
Changing the object
Serializing the changes by overwriting the old file
Is there a class that allows a file to be used as an object store, namely List<object> and working with it directly on the disk without having to complete the above processes?
Try DB4O. It seems to be a solution for your requirements.
I dont believe there is an out of the box solution for this. Just search on how to save arbitrary data in a file, and think up your own format.
You probably want to look at something like ESE which comes with Windows. There is a managed interface for it. Never used it though.
Either that or use a lightweight database e.g. SQLite, since effectively, if you want to add, remove and modify data on the disk, some kind of database is what you need.
Objectivity is another alternative. It supports computing across vast distributed networks or embedded in stand-alone devices that simply must not fail, enables persistent object management, virtually instantaneous traversal of complex, many-to-many relationships and graphs, and much more.
Im looking for a simple solution to serialize and store objects that contain configuration, application state and data. Its a simple application, its not alot of data. Speed is no issue. I want it to be in-process. I want it to be more easy-to-edit in a texteditor than xml.
I cant find any document database for .net that can handle it in-process.
Simply serializing to xml Im not sure I want to do because its... xml.
Serializing to JSON seems very javascript specific, and I wont use this data in javascript.
I figure there's very neat ways to do this, but atm im leaning to using JSON despite its javascript inclenation.
Just because "JSON" it's an acronym for JavaScript Object Notation, has no relevance on if it fits your needs or not as a data format. JSON is lightweight, text based, easily human readable / editable and it's a language agnostic format despite the name.
I'd definitely lean toward using it, as it sounds pretty ideal for your situation.
I will give a couple of choices :
Binary serialization: depends on content of your objects, if you have complicated dependecy tree it can create a problems on serializing. Also it's not very flexible, as standart binary serialization provided by Microsoft stores saving type information too. That means if you save a type in binary file, and after one month decide to reorganize your code and let's say move the same class to another namespace, on desirialization from binary file previously saved it will fail, as the type is not more the same. There are several workarrounds on that, but I personally try to avoid that kind of serialization as much as I can.
ORM mapping and storing it into small database. SQLite is awesome choice for this kind of stuff as it small (single file) and full ACID support database. You need a mapper, or you need implement mapper by yourself.
I'm sure that you will get some other choice from the folks in a couple of minutes.
So choice is up to you.
Good luck.
My question relates to the performance implications of reading application configuration data from an XML file.
I am building an application that lists information from a database and needs to know how to display the lists, depending on the types of data returned.
This is difficult to explain, but basically I would like to have an XML config file that lists the types and describes how to display them. This will allow me to change the display methods without re-compiling the application.
My question is really around performance. Given that my application will need to use this data many times during each page load...
Should I be reading directly from the XML file and parse it each time I need it?
Or should I cache the XML object and parse it each time I need it?
Or should I parse the XML once, generate some sort of object and cache that object?
My guess is option 3, but I'm basically fishing for best practice around this.
Thanks.
There is already a convention for this, called the App.config file.
It is XML, and Visual Studio has tooling support for it.
My suggestion is: Don't reinvent the wheel, if you can help it.
Now, given that your format is too complex for that, you probably want to go with option 3, but load it lazily.
I'm writing a simple program that will run entirely client-side. (Desktop programming? do people still do that?) and I need a simple way to store trivial amounts of data in a structured form, but really don't see any need to use a database system. What's more, some of the data needs to be serialized and passed around to different users, like some kind of "file" or perhaps a "document". (has anyone ever done that before?)
So, I've looked at using .Net DataSets, LINQ, direct XML manipulation, and they all seem like they would get the job done, but I would like to know before I dive into any of them if there's one method that is generally regarded as easier to code than others. As I said, the amount of data to be stored is trivial, even if one hundred people all used the same machine we're not talking about more than 10 MB, so performance is not as large a concern as is codeability/maintainability. Thank you all in advance!
Sounds like Linq-to-XML is a good option for this.
Link 1
Link 2
Tons of info out there on this.
Without knowing anything else about your app, the .Net DataSets would likely be your easiest option because WriteXml and ReadXml already exist.
Any serialization API should do fine here. I would recommend something that is contract based (not BinaryFormatter, which is type-based) as that will keep it usable over time (as your assembly changes).
So I would build a basic object model (DTO) and use any of:
XmlSerializer
DataContractSerializer
protobuf-net (you all knew it was coming...)
OO, simple, and easy. And easy to use for passing fragments of the data (either between users of to a central server).
I would choose an embedded database. Using something like sqlite doesn't seem to be an overkill for me. You may even try its c# port (http://code.google.com/p/csharp-sqlite/).