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/eaaCatal...taGateway.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
"Art" <ma*****@gmail.com> wrote in message
news:9e**************************@posting.google.c om...
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