persistence in winforms
While in the proccess of making a small data-massaging winforms app, I got to thinking about persistence in winforms. Almost all “real” applications have the ability to remember certain things between sessions. Most commonly, form size and location, as well as remembering some textbox values and such. These things aren't what you'd generally call “application options”, they are just those things that people think, “it should still be in the same state as when I left it”. Well, people wouldn't actually think those exact words... more like, “why the hell does that window keep popping up in random places.” or “do i really need to fill out this textbox every single time?”
And then I got to thinking about why I seperate these kinds of properties from more the properties that I consider application options. It seems to me that it comes down to the idea that I generaly consider options to be nerd knobs that change how the application works, while form state just changes the way it looks. I'm not sure why these things are so seperate in my mind. It all comes down to some object having a property that is persisted to an external format so that the values aren't lost when the application is shut down. That's the theoretical point of view.
In the practical world tho, options are different to deal with than UI stuff. I already have an options storage pattern I use when I need to do that stuff. I use a global options class that I store in IsolatedStorage via xml serialization. For changing options, I use that property editor box ( whatevertheheck that thing is called ) to edit the global instance. You see, that form just exposes the “real” options, and my code just talks to the options class to get the important stuff.
That pattern is kind of awkward when dealing with options that are more UI centered, such as form size and textbox values. If were handling a button click that dealt with a persisted textbox value, it seems more natural to talk to the TextBox itself, not the options class, to get/set the value. So now it's the textbox that is the real authority, and the fact that it is persisted is secondary. You see how this is opposite of my traditional view of options? I don't query the options form to get the values of the property box... I just talk directly to the class facade over the storage mechanism.
So how do I resolve this?
Obviously, I'd like the best of both worlds. Keep my current natural coding mechanisms, but use the same persistance framework for everything. I think the solution lies in making some kind of two-way databinding shim between controls and the persistance framework. I was thinking that it should be some component I can drag onto the form that exposes whatever databinding interface is required so that I can edit the databindings of my controls and just point whatever properties I want to store at my component. Now, I don't know a whole lot about how the winforms databinding stuff works, but from my minimal experience there, it seems like it should work.
If anybody knows of a project already out there that does this, I'd be interested in hearing about it.