Best practice for saving user data?

  • Thread starter Thread starter Art
  • Start date Start date
A

Art

Hi folks,

I'm writing a traditional desktop app using VB.NET and am stumbling
over what seems like a very basic question:

My app does not need to be connected to a server or another computer.
It just runs locally. So what is the best way to store user-entered
data? The app is like an address book, where users can enter contacts
and save the data.

I come from a web background, and so would be perfectly happy using
ADO.net to save the data to a local instance of Access or XML, etc.,
but I suspect that this is overkill and will require too much overhead
for my modest needs.

Should I just stream the data out to a txt file? Binary file?

I've been searching for a best-practices discussion of this using .Net
and am coming up dry (I'm sure I'm just not looking in the right
place!)

Thanks very much!

Art
 
Personally I would use a struct and then toss the struct into a bin file. It
sounds like you have structured data that would be a match for this type of
operation.

Just my own little opinion.
Thom
 
* "Thom said:
Personally I would use a struct and then toss the struct into a bin file. It
sounds like you have structured data that would be a match for this type of
operation.
Click to expand...

The choice IMO depends on if the data should be "human readable". A
binary format isn't the best way if the user should still be able to
exit the file in a text editor. In this case, XML would be more
appropriate. Using a dataset and storing it as XML file is one way to
do that.
 
Hi all,

Thanks for the suggestions--very helpful!

I've been tending to want to stay away from MSDE (although I love it!)
just because I'm not sure that my users will have it installed, and I
don't want to deal with installing it for them (this software will be
available to a wide range of users and systems). Also, I'm concerned
about the resources it might use. If I was deploying to a corporate
environment, I'd do it in a second, though!

I'm not at all concerned that the file be human-readable, so perhaps a
struct in a bin file is the way to go. I'll look also at XML, although
I'm concerned a bit about how large an XML file can get--it'd be nice to
keep the data files lean if I can. Still, I like the idea of using a
dataset--that's something I've at least got experience with.

Thanks again everyone!

Art

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
 
I would seriously consider a microsoft access database. This makes it very easy to you to allow the user to sort, select by criteria, etc. and the Access database engine is automatically added to the bin directory for distribution.
 
Art,
First I would decide which Domain Logic Pattern fit my application the best.
Then based on the Domain Logic Pattern I would consider data storage (RDBMS
(Access, SQL Server, Oracle, AS/400), XML file, binary serialization, other)
and select a Data Source Architectural Pattern. Sometimes the data storage
drives the Domain Logic Pattern.

For information on Domain Logic & Data Source Architectural Patterns see
Martin Fowler's book "Patterns of Enterprise Application Architecture" from
Addison Wesley.
http://www.martinfowler.com/books.html#eaa

http://www.martinfowler.com/eaaCatalog/


I don't have any good links on data storage considerations. If there were no
specific RDBMS requirements or specific XML requirements I favor binary
serialization!


Martin Fowler's book explains when you may want to use a traditional Domain
Model & Data Mapper pattern:
http://www.martinfowler.com/eaaCatalog/domainModel.html
http://www.martinfowler.com/eaaCatalog/dataMapper.html

verses a Table Module & Data Gateway patterns:
http://www.martinfowler.com/eaaCatalog/tableModule.html
http://www.martinfowler.com/eaaCatalog/tableDataGateway.html

Martin also offers a couple of other useful patterns that can be used
instead of or in conjunction with the above patterns.

The System.Data.DataTable is an implementation of a Record Set pattern:
http://www.martinfowler.com/eaaCatalog/recordSet.html

Rockford Lhotka's book "Expert One-on-One Visual Basic .NET Business
Objects" from A! Press provides a pre-implemented variation of Fowler's
Domain Model & Data Mapper patterns.
http://www.lhotka.net/



Generally if there is no real logic behind my domain objects, I would use
the DataSet OOM coupled with a Table Module & Data Gateway patterns. As the
classes themselves are not really living up to their potential! :-) The
Table Module & Data Gateway patterns may be implemented in a single class or
two classes. Again I would consider using a Typed DataSet.

However if there is significant logic behind my domain objects, I would then
favor the Domain Model & Data Mapper patterns.

Depending on the needs of the project I would consider Fowler's other
patterns...

Hope this helps
Jay
 
Thanks, Dennis!

Several others have mentioned using an MDB file as a backend. I didn't
realize, though, that the engine would be automatically included with my
bin--is this freely redistributable? In other words, would I be able to run
this solution on the computers of people who don't own Access?

Also, how does this compare to the other options mentioned (filestream,
MSDE, etc.) in terms of overhead and speed?

I'll, of course, look for more info on google, but I'd certainly appreciate
any additional thoughts you might have.

Thanks so much!

Art

Dennis said:
I would seriously consider a microsoft access database. This makes it
Click to expand...
very easy to you to allow the user to sort, select by criteria, etc. and the
Access database engine is automatically added to the bin directory for
distribution.
 
Art,

1. It is freely distributable.

2. It is fairly quick for small to medium sized databases, with under
50,000 records in a table. More than that and you should look at MSDE.

3. It has a lot smaller footprint than MSDE.

4. It is an ideal solution if you are only going to be running one
workstation on the database at a time. If you are going to need multple
workstations on the same database at the same time you should probably
consider MSDE.

5. MSDE is also freely distributable. It can be a little tricky getting it
included in your setup project and getting a database attached on the target
machine.

-Sam Matzen
 
Back
Top