 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / XML / October 2003Managing XmlDocument Lifetime
I'm currently writing a class to manage per-user configuration files, using the same format as the app.config file. This will be used in a Winforms app to manage user options, window positions, etc. When instantiated, the object will be available as a service at the application level. The question I have is about the most efficient way to manage the lifetime of the XmlDocument object that contains the XML file itself. Currently, I do the .Load() the first time the service is called on and then store it in a protected property of the service. So... 1. Is it more efficient to just open and close the document each time it's viewed/updated? 2. Is it better to keep it open for the lifetime of the object (which is also the lifetime of the app domain)? 3. If I keep it open all the time, would it be better if I called Save() when various changes are made, or just when the object is shutdown? Both? 4. In terms of an on-disk resource being used as a memory mapped structure like this, what's the cleanest way to deal with updating/saving the file at destruction? Put a Save() in Finalize, or should I go the route of implement IDisposable? Thanks in advance for any advice/insight on this. J First a level set on some terminology. XmlDocument.Load does not keep the file open. So the right phrase would be "load/save the document" not "open/close the document". You can have a "loaded" document, but the file is closed. XmlDocument does not use memory mapped files. When Load() returns, the file is closed. For example, others could write to it and your in-memory copy would then be stale. Also your use of the term "service" could get confused with NT services running out of process from your application process. If this is what you are thinking then you also need to consider multiple instances of your app running at the same time, and how they would potentially clobber the file on disk if they tried to write at the same time, or get file locked exceptions. I would recommend against this and keep it all in-proc. As for performance, it all depends on how often you access/update this info and how big the file gets. For example, if you update the state object every time you receive an OnResize or OnMoved event then I wouldn't "load/save" this often. What I normally do is load the XmlDocument when my app starts, populate my app state from it, then throw it away, then when my WinForm gets the OnClosing() event, I gather up all the app state I want to persist and write it to disk (either via XmlDocument or directly via XmlTextWriter, or a XmlSerializable object). I do NOT wait till finialization of any object because that is a bit late in the game, because I want to check the final window state before saving to disk, and OnClosing() is the right time to do that. If you are trying to keep this state management separate from the WinForm then you could make it IDisposable, and have the contract that the WinForm is supposed to set the final state and call Dispose() during OnClosing, that way the persisted state will most likely reflect what the user expected. > I'm currently writing a class to manage per-user configuration files, > using the same format as the app.config file. This will be used in a [quoted text clipped - 25 lines] > > J Chris, Thanks for your reply. > XmlDocument.Load does not keep the > file open. So the right phrase would be "load/save the document" not > "open/close the document". Interesting... I didn't realize that and assumed that the file on disk was open until the XmlDocument that had Load()'ed it went out of scope. > Also your use of the term "service" could get confused with NT services > running out of process from your application process. Sorry for the confusion... no, I'm not referring to NT services. WHen I say that this "user preference" component is a service, what I mean to say is that it's running inside of the WinForms app and is intended to be "available to all" within the app. > As for performance, it all depends on how often you access/update this info > and how big the file gets. For example, if you update the state object > every time you receive an OnResize or OnMoved event then I wouldn't > "load/save" this often. I think the info could be accessed quite regularly during the app's "object lifetime". Updating it will be less frequent. It simply stores user preferences for all sorts of things -- window size/positions, MRU lists, all the settings in a Tools->Options dialog, etc. > What I normally do is load the XmlDocument when my app starts, populate my > app state from it, then throw it away, then when my WinForm gets the > OnClosing() event, I gather up all the app state I want to persist and write > it to disk (either via XmlDocument or directly via XmlTextWriter, or a > XmlSerializable object). Interesting... I think I'm doing that now, in a sense. Knowing what you just told me about the Load() vs. "open", it would seem that I've got an XmlDocument that serves as the "settings state" object for the app. As the wrapper for that XmlDocument object goes out of scope, I call the .Save() method to store the current settings state back to disk. > If you are trying to keep this state management separate from the WinForm > then you could make it IDisposable, and have the contract that the WinForm > is supposed to set the final state and call Dispose() during OnClosing, that > way the persisted state will most likely reflect what the user expected. I'll have to look into this, as it's certainly possible that this component could be used in other types of applications for generic settings/preferences that don't really belong in app.config. I don't know much of anything about the IDisposable interface, though, so it's new territory. Thanks again. Cheers, J Just a comment, if you are saving user settings to files, have a look at the System.IO.IsolatedStorage namespace. It allows you to store files on a per-user / per-assembly basis without using a proprietary method or the registry. It would be good practice to separate application settings from user settings. Colin > Chris, > [quoted text clipped - 56 lines] > > J Hi Colin, Currently, I'm using Environment.SpecialFolders.ApplicationData -- it's specific to the user, non-local, and it will roam with them as they go from machine to machine. While I've looked at IsolatedStorage as well, I'm not sure that I see the benefit of using it over the ApplicationData location -- at least for this purpose. If you have any input on that, I'd love to hear it. Thanks, J > Just a comment, if you are saving user settings to files, have a look at the > System.IO.IsolatedStorage namespace. It allows you to store files on a [quoted text clipped - 72 lines] > > > > J Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.