Design: Should objects persist themselves to the DataBase?

[Ed Sutton]

I am a DB newbie struggling with the best way to load and save objects
from the database. Advice is much appreciated. My current thoughts:

1 - Iterate through the data base retrieving the data needed to create
the collection of objects. Do the reverse to save.
2 - Make the objects load and save themselves to the data base
3 - Persist the actual objects themselves in the database?

I like the following article that uses attributed programming to persist
the objects.

A Data Access Layer to persist business objects using attributes and
reflection - Part I
http://www.codeproject.com/cs/database/dal1.asp

My target is a C# WinForms app that loads a collection of objects into a
treeView. The user may edit these objects and changes are saved to the
database.

Thanks in advance for any direction or advice,

-Ed

 

[Guest]

The persistence layer model is rather nice. Rocky Lhotka has also defined his
own data pool type methodology in his books on .NET objects (one for VB.NET
and one for C#). I like his model, overall, but I have not worked through it
deeply yet.

Once ObjectSpaces are around (Longhorn timeframe), you will be able to map
objects to relational data, which will be nice. Overall, the objects do
control their lifetime in most OO models and are aware or semi-aware.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Ed Sutton]

Hi Gregory,

Thank you for your reply. I will read some reviews on Rocky Lhotka's books.

Any thoughts on the proper way to update objects? For example, assume
my object loads itself from the database and some of the contained data
changes. Do you set a dirty flag and iterate through the collection of
objects later? Use transactions? Or do you simply tell all objects to
save themselves to the database regardless if there data may have changed?

Thanks again,

-Ed