I am basically wanting to fetch an IDIctionary from a place which is global setting repository. We basically use IOC and I had put it there but for certain reasons , it has to be moved to web.config. I have gone through some articles and the nearest I got was this:
http://brijbhushan.net/2011/04/21/how-to-store-custom-objects-in-web-config/
Again this article talks about storing it programmatically. I just want something simple where a programmer can come at the design time and store or change my dictionary and that's it. Any idea on how to achieve this?
The web.config file is not really a good place to store and deserialize objects from. I would recommend using XAML files for this purpose. This is much more appropriate and done by MS themselves. You can get more information here http://blogs.microsoft.co.il/blogs/bursteg/archive/2009/05/18/xaml-in-net-4-0-serialization-and-deserialization-using-xamlservices.aspx.
Related
I am working on a text-based game in WPF using MVVM. I am hoping to get some advice regarding managing created objects in my project. I would like to store and access my created objects in/from a central location. There are several different types of objects that I need to manage and I currently have everything relevant contained in a singleton class, which I have named DataManager, for easy access. When applicable, I'm storing, exposing, and populating ObservableCollection<MyObject>s in DataManager. From there I create properties in my ViewModels that get the required object(s) from DataManager.
So far this hasn't caused any problems, but I would like to get some input before I progress too far to avoid having to rewrite my code (again). Would it be worth looking into a database for a project like this? If not, can anybody provide any feedback or suggestions on how to do this better or more properly? Like I said, I would just like to know the 'correct' way to store and access created objects or collections of objects from a location that is globally accessible.
I would certainly appreciate any advice you could give me on this issue and I would be open to any suggestions. I would like to learn how to do this right.
IMO, what you're doing is OK.
Regarding the DB question, a DB is to store data in a persistent manner, not in a temporary manner. That means that if you plan to "save" and "load" lots of data in your game, then a DB should be appropiate, otherwise your approach seems OK to me.
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.
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/).
I am currently working on a large-scale website, that is very dynamic, and so needs to store a large volume of information in memory on a near-permanent basis (things like configuration settings for the checkout, or the tree used to implement the menu structure).
This information is not session-specific, it is consistent for every thread using the website.
What is the best way to hold this data globally within ASP, so it can be accessed when needed, instead of re-loaded on each use?
Any AppSettings in web.config are automatically cached (i.e., they aren't read from the XML every time you need to use them).
You could also manually manipulate the cache yourself.
Edit: Better links...
Add items to the cache
Retrieve items from the cache
Caching Application Data
It's not precisely clear whether your information is session specific or not...if it is, then use the ASP Session object. Given your description of the scale, you probably want to look at storing the state in Sql Server:
http://support.microsoft.com/kb/317604
That's the 101 approach. If you're looking for something a little beefier, then check out memcached (that's pronounced Mem-Cache-Dee):
http://www.danga.com/memcached/
That's the system that apps like Facebook and Twitter use.
Good luck!
Using ASP.NET caching feature is a good option I think. In addition to John's answer, you can use Microsoft's Patterns & Practices team's Caching Application Block.
This is a good video exploring the different ways to can retain application state.
http://www.asp.net/learn/3.5-videos/video-11.aspx
It brushes on the Application object which is global for the whole application, for all users and shows you how to create a hit counter (obviously instead of storing an integer you could store objects). If you need to make changes, you do need to use a lock for concurrency, and I'm not sure how it handles LARGE amounts of data because I've never had to keep that much there.
I usually keep things like that in the Application object.
If the pages are dependent upon one another and they post to one another, you could use the page's request object. Probably not the answer you're looking for, but definitely one of the smallest in memory to use.
I have run into the same situation in the past and found an interface to be the most scalable solution. Application cache may be the answer today, but will it scale to meet your needs?
If you need to scale up, you may find cookies, or some type of temp database storage to be the trick. Simply add a new method to your interface, and set the interface to choose the "mode" from web.config.