Persistence Question

  • Thread starter Thread starter Mike
  • Start date Start date
M

Mike

Hi,

Right now I am trying design user data persistence in my winforms app and
have a few questions. Right now the app is designed to save to a local file
however down the road it might be changed to saving to a database. So, I
was thinking about designing a dataset that if I do switch to a database
that it will be easily be converted and dataset could be written to file as
of right now. Is this a good idea or should I just create a custom class?
Also, I have 4 forms which can be open at the same time and can be accessed
in no particular order and do need to persisted. How can I save each?
Should I save to the dataset/class at the time when each form is ready to
persisted and persist the dataset/class each time? Or should I have a custom
class for each form and persist each class until the time when each form
needs to be saved and then add each to the dataset/class?

Thanks for your time
 
Mike said:
Hi,

Right now I am trying design user data persistence in my winforms app and
have a few questions. Right now the app is designed to save to a local file
however down the road it might be changed to saving to a database. So, I
was thinking about designing a dataset that if I do switch to a database
that it will be easily be converted and dataset could be written to file as
of right now. Is this a good idea or should I just create a custom class?
Also, I have 4 forms which can be open at the same time and can be accessed
in no particular order and do need to persisted. How can I save each?
Should I save to the dataset/class at the time when each form is ready to
persisted and persist the dataset/class each time? Or should I have a custom
class for each form and persist each class until the time when each form
needs to be saved and then add each to the dataset/class?
Click to expand...

If you're talking about storing the state of a form, I quite like the idea
of mementos, which are essentially a collection of state/data associated
with a class. You could give each form a GetMemento and SetMemento method
which allows you to save/restore the forms values.

The Memento object itself could just be a DataSet, or a home-grown class
specifically designed to store the state associated with a given form.

If you go for datasets to store form state, then you can easily save/load
the dataset to/from an XML file. If you decide to create custom objects to
store the forms state then you can design them to be serialized using Xml or
some other method.

Personally, I'd probably scoure MSDN for the recommended approach! If I
couldn't find it, then I'd start by using a simple DataSet for storing the
data. If this started to look like it wasn't up to the job, I'd switch to
home-grown objects. I'd also have a SettingsStorage class which would know
how to store the DataSets (or objects). For example, it may know to write
them to XML files, or to a database, or to a binary file, or to another
computer using SOAP etc.

The book about SharpDevelop IDE (search Amazon) talks about using mementos
for storing form state. Also, searching google for the Memento design
pattern may give some interesting resources. Mu first stop may be MSDN
though - as I'm sure this problem has been covered!

HTH!

Tobin
 
As Tobin said, the Memento Pattern is probably a good option here. Just
save the members you actually need to keep things small. Then persist the
memento using xml or binary serializer (xml text probably easier to get in
and out of database, but have not did much blob work on Sql to know if that
is easy now.) Then if/when you switch to database, you can save the xml
text stream to a single text field in the database. Not sure at this point
if using a typed dataset would buy you anything but overhead - but would
depend on your needs.
 
Back
Top